[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: RE: Declarative programming requires a different mindset

• From: Jonas Mellin <jonas.mellin@his.se>
• To: "Costello, Roger L." <costello@mitre.org>
• Date: Thu, 18 Mar 2010 00:48:53 +0100

Costello, Roger L. skrev:
> Hi Folks,
>
> I've had some additional insights into declarative programming that I would like to share.
>
> The three main constructs used in programming are:
>
>   - Loops 
>
>   - Conditional
>
>   - Sequence
>
> I have always thought of these constructs in terms of "Do this, then that." That is, I thought these are imperative constructs only. But now I understand that these are also declarative constructs. 
>
> Here's how to declaratively think about the constructs.
>
>
> Ways of Thinking about Loops
>
> Example Loop: 
>
>     for $i in //Member return A, B, C
>
> Imperative: loop through each <Member> element and do actions A, B, C.
>
> Declarative: this A, B, C description applies to each <Member> element.
>
>
> Ways of Thinking about Conditional Statements
>
> Example Conditional: 
>
>     if (empty(//Member[999])) then A else B
>
> Imperative: if there is no 99th <Member> element then do action A, else do action B.
>
> Declarative:  this description A is for the case where the old document does not contain a 999th <Member> element. And this description B is for the case where the old document _does_ contain a 999th <Member> element.
>
>
> Ways of Thinking about a Sequence of Statements
>
> Example Sequence: 
>
>     delete node $i/Name,
>     replace node $i/@id with 
>             attribute {'id'} {data($i/Name)}
>
> Imperative: delete the <Name> element, then replace the value of the id attribute with the value of the <Name> element. (Obviously, this is nonsensical in an imperative programming.)
>
> Declarative: in the new document there will be no <Name> element. In the new document the id attribute's value will be the value of the <Name> element in the old document.
>
>
> To recap: declarative programming focuses on describing what you want in the new document, relative to what was in the old document. How a machine takes that declarative description and accomplishes it, is transparent.
>
> Question: When you create XSLT transforms or XQueries, how do you maintain a declarative mindset, and avoid slipping back into an imperative mindset?
>   
Personally, I think in terms of CA/production rules (which goes way back 
to 1970-1980s) for XSLT. Essentially, you have a set of rules and the 
one which is matching most specifically is the rule that is applied. 
Modes are used to divide rules into different classes, so that some 
rules are only active if a condition of an enabling rule is true. The 
ordering of rules are primarily controlled via applying the rule engine 
to different selections/projections of the elements via XPath 
expressions. I trained in Prolog, OPS5 and similar languages before 
meeting XSLT.

Concerning XQuery, I think in terms of relational databases and SQL 
Queries. My major frustration is that a simple issue of handling 
multiple projections, a simple thing in SQL, is such a pain in XQuery. 
Apart from that, all SQL parts can be expressed as XQuery parts. Vice 
versa may require some more care, in particular since multiple 
projections does not have a 1-1 correspondance with SQL statements.

In both cases, data modelling is essential. It is the key to effective 
declarative programs. If the data model is inappropriate (e.g., it 
require frequent resorting of elements to perform the Query), then 
something is amiss. Personally, I tend to do ER-modelling and then 
choose some implementation in whatever data model is available (SQL, 
XML, etc.). The implementation depends largely on what queries or rules 
that should be applied to it. The same thing is true for, for example, 
modelling relation databases and implementing them in SQL.

P.S. If you want to try something that forces you to think declarative, 
then you should try manually to configure the sendmail daemon in 
UNIX/Linux. Only kidding, I have done it and it was HORRIBLE D.S.

Regards / Jonas Mellin
> /Roger
>
> _______________________________________________________________________
>
> XML-DEV is a publicly archived, unmoderated list hosted by OASIS
> to support XML implementation and development. To minimize
> spam in the archives, you must subscribe before posting.
>
> [Un]Subscribe/change address: http://www.oasis-open.org/mlmanage/
> Or unsubscribe: xml-dev-unsubscribe@lists.xml.org
> subscribe: xml-dev-subscribe@lists.xml.org
> List archive: http://lists.xml.org/archives/xml-dev/
> List Guidelines: http://www.oasis-open.org/maillists/guidelines.php
>
>   

• References:
  • Declarative programming requires a different mindset
    • From: "Costello, Roger L." <costello@mitre.org>
  • RE: Declarative programming requires a different mindset
    • From: "Costello, Roger L." <costello@mitre.org>