Re: Re: mapping (Was: Re: Re: . in for)

Dimitre Novatchev <dnovatchev@xxxxxxxxx> wrote
> > 3. Higher order functions. I'm walking on thin ice here but i
> >  believe this requires the possibility to compose lambda expressions
> Wrong.

Thank you for the correction, as you and others pointed out i was
seriously confused here. 

Now when you introduced your functional programming techniques you
used it in conjunction with the term "generic template", which got
stuck. Let me repeat the essentials of this technique from my point
of view here, so we may discuss differences later:

   <xsl:stylesheet version="1.0"
      xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
      xmlna:fp="some.uri.for.private.use">

     <!-- Artificial element used to refer to a function -->
     <fp:ref-to-myfunc/>

     <!-- The function "myfunc", implemented as template -->
     <xsl:template match="fp:ref-to-myfunc">
       ...
     </xsl:template>

     <!-- The "generic template" which takes a function
        reference as parameter -->
     <xsl:template name="some-framework-template">
       <xsl:param name="funcref"/>
       ...
       <!-- invoke the function passed as parameter -->
       <xsl:apply-template select="$funcref"/>
       ...
     </xsl:template>

     <!-- Random sample template ... -->
     <!xsl:template match="stuff">
      ...
       <!-- ... for demonstrating how to call the "generic
         template", passing a specific function as parameter -->
       <xsl:call-template name="some-framework-template">
         <xsl:with-param name="funcref"
             select="document('')/*/fp:ref-to-myfunc/>
       </xsl:call-template>
       ...
     </xsl:template>
     ...
  <xsl:stylesheet>
Am i on the right track (perhaps apart from nomenclature)? I know
that the mechanism for invocation could be varied somewhat.

The usual use case is that the "generic template" implements
some algorithm, often in a recursive form. You presented
sorting, summation+running totals for orders and some other
stuff; it could also be used for example for numeric integration.
Actually this shows that functional programming on the XSLT
level is already reality in XSLT 1.0 to some extend (with the
caveat that for functions returning function references,
the xx:node-set() extension function is necessary; is this
correct?).

The interesting point is now: how could we profit from functional
programming elements on the XPath level? Your generic sort template
is probably a good candidate. Most of the generic solutions for
iterating over a node set are probably covered by other new standard
stuff, so they're not as convincing as they used to be.

For others: Unless i'm mistaken there is still no easy way to sort
order positions by price*quantity (or price*key('exchange-rate',currency))
in XSLT 2.0, so the generic sort template is still useful.   

> And to say that the "FP stuff" is not usable means not to understand what FP
> is.
It was meant in the sense that for many people "more compact" is
also "more usable". Imagine you could pass an expression as parameter
to your generic sort template without having to encapsulate it in a
template first.

Regards
J.Pietschmann

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list