RE: [xml-dev] RE: Declarative programming requires a different mindset

[w3c@drrw.info]

In Prolog there are two ways data gets into the function:

1) explicitly via parameter passing e.g. solve(in,_,_,out);  

    // this tells the parser it has bound parameters for in and out, but the other two value sets are unbound (e.g. you either don't care to state those, or you want the function to figure those out).  

2) via assertion predicates - this is akin to xsl:apply-templates - where you need to understand the information patterns the function is expecting

Notice that xsl:function() has the same style of constraints - provided you understand the inputs and outputs - if you import the code that into your own program - it will run - self contained.

Whereas with traditional programming you may get all kinds of code dependencies and things that need to be declared and so on - along with unwanted side effects.  With object programming - aka Eclipse and Java - cutting and pasting across programs - the visual environment will attempt to hint for you what you need to put in to get things to clean compile - but it is tracking down those side effects and correct them that can be very challenging.

DW

-------- Original Message --------
Subject: Re: [xml-dev] RE: Declarative programming requires a different
mindset
From: Olivier Rossel <olivier.rossel@gmail.com>
Date: Wed, March 31, 2010 10:39 am
To: w3c@drrw.info
Cc: Kendall Shaw <kshaw@kendallshaw.com>, xml-dev@lists.xml.org

I am no expert at Prolog, but I have a quite good understanding of XSLT.
So i would consider myself non-newbie when it comes to declarative programming.

I would like more information about a statement taken from that
(interesting) conversation.

"In Prolog, components of your program are highly compartmentalized -
so it is especially
easy to grab blocks of code and graft them into another process."

As far as I know, reusability in declarative programming is a lot of human work.

For example, in XSLT, you cannot evaluate the relevancy of a
<xsl:template> just by reading its code.
You need a very good understanding of the input schema and of *all*
the other <xsl:template>s.
And, eventually, running the stylesheet is the only way to clearly
understand the relationships between the <xsl:template>s.

My opinion (to be discussed):
extracting a subpart of declarations and reusing it in another context
requires a very deep knowledge of the code structure and of the facts
that will happen in that given context.
In one word: reusability is *very* tedious and error-prone.

On the contrary, when it comes to statically-typed imperative
languages such as Java, you have a bunch of highly effective static
analysis tools to assist you when dealing with refactioring,
modularity, code extraction, static debugging, a priori understanding
of data structures, data flows and runtime flows.

So my question is:
what is the R&D status of static analysis tools for declarative
programming languages?






On Wed, Mar 31, 2010 at 4:05 PM, <w3c@drrw.info> wrote:
> Kendall,
> Excellent points!
> I would say however that personally I try to use the declarative approach as
> my go to paradigm in xslt - and resort to procedural to handle edge
> conditions and explicit constructs.
> IMHO - this also results in smaller more compact and easier to maintain
> code.  As your example below illustrates.
> The declarative approach by its very nature supports the general case of
> inputs - so the code is not brittle - but instead is adaptive to new input
> patterns that its author had not previously encountered or anticipated
> directly.
> DW
>
> -------- Original Message --------
> Subject: Re: [xml-dev] RE: Declarative programming requires a different
> mindset
> From: Kendall Shaw <kshaw@kendallshaw.com>
> Date: Thu, March 25, 2010 5:47 pm
> To: "xml-dev@lists.xml.org" <xml-dev@lists.xml.org>
>
> "Costello, Roger L." <costello@mitre.org> writes:
>
> [about declarative programming]
>
> I enjoy your various posts with high level questions like this. I hope
> you will keep asking them.
>
> The question of what "the definition" of "declarative programming" is,
> is unanswerable, I think. People use words as tags to coordinate
> discussion of topics. A conversation often takes the form:
>
> Here is a phrase to use as a mnemonic: "..."
>
> Here are more phrases asserting the meaning of the mnemonic phrase.
>
> Here are more phrases that are meant as an invitiation for you to
> discuss a topic in terms of those phrases.
>
> In such a discussion you make a point by referencing the mnemonic phrase
> and redefining it.
>
>>> A clearer distinction is whether or not the program involves mutable
>>> state
>> variables.
>>
>> Since XSLT variables don't vary, are all XSLT programs declarative?
>>
>> Surely that's not the case.
>
> It's worthwhile to think of declarative programming as a style, in my
> opinion, and not all XSLT programs are written in a declarative style. A
> declarative programming language would be one that makes declarative
> programming easier than if it were not a declarative programming language.
>
> A program can have parts that are writte in a declarative style and
> parts that are not.
>
> I also think it is worthwhile to think of functional programming and
> declarative programing as different things.
>
> Perl is not a functional programming language, but you can write perl in
> a declarative style, e.g.:
>
> document(title(), body());
>
> is written in a declarative style.
>
> You can also program in functional programming style using a procedural
> language. I suspect you could program in a "less functional" style using
> a functional programming language, but I can't think of an example.
>
>> Would someone give an example of XSLT code that is clearly imperative?
>
> This:
>
> <!-- given a matching author author -->
> <xsl:variable name="author" select="f:matching-author(.)"/>
> <!-- an author-link is the matching author's name and www address -->
> <author-link>
> <xsl:copy-of select="$author/name"/>
> <xsl:copy-of select="$author/www"/>
> </author-link>
>
> is more declarative and less imperative than:
>
> <!-- output an author-link start tag -->
> <xsl:text disable-output-escaping="yes">&lt;author-link></xsl:text>
>
> <!-- get the matching author -->
> <xsl:variable name="author" select="f:matching-author(.)"/>
>
> <!-- output it's name -->
> <xsl:copy-of select="$author/name"/>
>
> <!-- output it's www address-->
> <xsl:copy-of select="$author/ww"/>
>
> <!-- output an author-link end tag -->
> <xsl:text disable-output-escaping="yes">&lt;/author-link></xsl:text>
>
> So, I think declarative programming is not a precisely definable
> concept. It refers to those parts of a programming style that you
> describe as being declarative.
>
> Kendall
>
> _______________________________________________________________________
>
> 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
>
> _______________________________________________________________________
> 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

_______________________________________________________________________

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