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

[Dimitre Novatchev <dnovatchev@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?

I don't understand this question completely, however the answer can
probably be found here:

http://web.archive.org/web/20070222111927/http://www.idealliance.org/papers/extreme/proceedings/xslfo-pdf/2006/Novatchev01/EML2006Novatchev01.pdf


-- 
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 9:17 AM, Olivier Rossel
<olivier.rossel@gmail.com> wrote:
> 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
>>>
>>
>