XML.orgXML.org
FOCUS AREAS |XML-DEV |XML.org DAILY NEWSLINK |REGISTRY |RESOURCES |ABOUT
OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
RE: [xml-dev] RE: Declarative programming requires a different mindset

I have to say I agree with David, here.  I'm certainly no expert on declarative programming, but as far as I can tell, "purely declarative programming" is (at least with current technology) an illusive paradigm.  That's because, no matter how you write your code, if you dig deep enough, at some point it gets interpreted into the instruction set for the platform on which it is running.  Every architecture I know of, from RISC to x86, uses imperative machine instructions—add, multiply, jump, branch, etc.
 
Thus, any declarative construct must, at some point, be processed into a sequence of imperative instructions on how to apply the construct.  For some constructs, this processing is hidden, but that doesn't mean it's not happening; for more complex constructs, the programmer may have to supply some part of the processing instructions.  It seems to me that trying to make a complete distinction between the two eventually becomes rather pedantic.
 
By the way, the discussion on this topic has been absolutely fascinating!
 

Doug Glidden
Software Engineer
The Boeing Company
Douglass.A.Glidden@boeing.com



From: David [mailto:dlee@calldei.com]
Sent: Thursday, March 25, 2010 07:59
To: xml-dev@lists.xml.org
Subject: Re: [xml-dev] RE: Declarative programming requires a different mindset

To me (and please explain why I'm wrong)
Saying that Declarative Programming languages dont "tell the computer what to do" is misleading, or outright false.
Even in languages like XQuery and XSLT ... There's few constructs that dont have some sense of operational instructions.
The literal element constructor in XQuery may come close where you simply enter what you want the output to be
    <XML>something</XML>

But everything else, such as variable declarations, FLOWR expresions, recursion etc have some mannor of 'telling the computer what to do'.
Just not in as direct way as procedural/imperative programming.

Your example is a good one.  Your giving a "recipe" or "instructions" on 'how to do'  the substring-before-last ... operation.
Is this "purely declarative' ?   I dont know.
Does it matter ?

IMHO ... actual declarative languages like XQuery and XSLT (those are the ones I'm most familiar with) you still have to give the computer
directions on 'what to do' and quite a bit of 'how to do it'.   Just not quite so much on the 'how' part as imperative languages.
But I dont see it as quite black & white.   To me it seems somewhat fuzzy.

I'm not sure how one might express, purely declarative , a new operation built out of existing atoms without some kind of direction on how to get there from here.   Even purely 'rule based' languages still have the assumption that rules will be "evaluated" ...
Maybe there is some strict dividing line ... I'm not sure what it is.

For anything complex, In languages I know, you have to somehow give enough direction to the system to tell it how to do it.
How else ?  How would you write substring-before-last without giving directions on how to accomplish it or what it meant ?
Purely by example ? Inductive programming? But that may be really really difficult to make sure the examples you gave were good enough to express what you really mean.

Am I totally missing the boat here ?








-------------------------
David A. Lee
dlee@calldei.com
http://www.calldei.com
http://www.xmlsh.org

On 3/25/2010 7:32 AM, Costello, Roger L. wrote:
82B6502D-2598-489F-BA47-FB33D572D800@mimectl" type="cite">

Hi Folks,

Yesterday’s responses were outstanding and illuminating. Thank you.

I learned that a declarative program describes the relationship of the output to the input.

This raises new questions. Let’s take an example. Suppose that this is the input:

<XML-file>http://www.example.org/book.xml</XML-file>

I want the output to contain the URL and the filename separated:

<XML-file>

    <URL>http://www.example.org/</URL>

    <Filename>book.xml</Filename>

</XML-file>

This XSLT code describes the relationship of the output to the input:

<xsl:template match="XML-file">

    <xsl:variable name="url"

                  select="f:substring-before-last(., '/')" />

    <XML-file>

        <URL>

            <xsl:value-of select="$url" />

        </URL>

        <Filename>

            <xsl:value-of select="substring-after(., $url)" />

        </Filename>

    </XML-file>

</xsl:template>

I believe this code is declarative. Do you agree?

Note my use of the function, f:substring-before-last(). There is no such built-in function, I created it. Below is how I implemented it. The implementation doesn’t seem descriptive. It seems quite recipe-like:

 

   Get the substring before $delimiter and output it,

   then output $delimiter, and then recurse.

 

It seems quite imperative. Do you agree?

If I stuff a bunch of imperative code into functions, and the “main” code is declarative, do I still have a declarative program?

Here’s my implementation of f:substring-before-last():

<xsl:function name="f:substring-before-last" as="xs:string?">

    <xsl:param name="string" as="xs:string" />

    <xsl:param name="delimiter" as="xs:string" />

       

    <xsl:if test="contains( $string, $delimiter )">

        <xsl:variable name="url">

            <xsl:value-of

               select="substring-before( $string, $delimiter )"/>

            <xsl:value-of select="$delimiter"/>

            <xsl:value-of

               select="f:substring-before-last(substring-after

                        ( $string, $delimiter ), $delimiter)" />

        </xsl:variable>

        <xsl:value-of select="$url" />

    </xsl:if>         

</xsl:function>

/Roger


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS