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

[Olivier Rossel <olivier.rossel@gmail.com>]

interesting point !

my question is:
how did you ensure that your library (which is declarative
programming, if i understand correctly)
will not be polluted by other declarations coming from other part of
the program, that may interfer with
your own workflows?


On Wed, Mar 31, 2010 at 6:10 PM, Dimitre Novatchev <dnovatchev@gmail.com> wrote:
>> 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.
>>
>
> This is far from the truth. Any code can be reused if it is
> implemented as an <xsl:function>.
>
> The FXSL library for functional programming in XSLT (both 2.0 and 1.0)
> is one particular example of reaching and providing an extremely high
> degree of reusability.
>
> Just one "small" example: In FXSL it was very easy to convert and
> provide all standard XPath 2.0/XQuery F&Os to higher order functions.
>
> Most of the functions in FXSL know nothing about who and how is going
> to use them -- they are used in myriad of ways that are unplanned and
> unthought of. Such genericity and power is much more difficult (if
> possible at all) to achieve with an imperative language.
>
> Why is this so?  Maybe it would help to know that FXSL is mainly a
> re-write of Haskell's Prelude module in XSLT.
>
>
>
>
> --
> Cheers,
> Dimitre Novatchev
> ---------------------------------------
> Truly great madness cannot be achieved without significant intelligence.
> ---------------------------------------
> To invent, you need a good imagination and a pile of junk
> -------------------------------------
> Never fight an inanimate object
> -------------------------------------
> You've achieved success in your field when you don't know whether what
> you're doing is work or play
>
>
> On Wed, Mar 31, 2010 at 7:39 AM, Olivier Rossel
> <olivier.rossel@gmail.com> wrote:
>>
>> 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
>>
>