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

[Dimitre Novatchev <dnovatchev@gmail.com>]

Now, that I think I maybe start to understand the question:

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

The answer is that all FXSL functions are in the  "http://fxsl.sf.net";
namespace, and all of its templates, or templates passed to it as
parameters, are  matching nodes in the same "http://fxsl.sf.net";
namespace and/or are in mode  ( {http://fxsl.sf.net}, "FXSL" ).

In this way one can only mess up things if they start writing
functions in the "http://fxsl.sf.net"; namespace, which will have
almost the same result as if they start writing their own stuff in the
"http://www.w3.org/1999/XSL/Transform"; or
"http://www.w3.org/2005/xpath-functions"; namespaces.


-- 
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:29 AM, Dimitre Novatchev <dnovatchev@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?
>
> 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
>>>>
>>>
>>
>