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 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


[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