Re: [xsl] Functional programming in XSLT

["David Rosenborg" <david.rosenborg@xxxxxxxxxx>]

Hi Alexey,

Some comments in addition to the ones just posted by Jeni:

> 2. It is ultimate. Once xsl:lambda is introduced, there unlikely will be
> a need for another construction implementing similar functionality.
 
> 3. It is ortodoxal. Based on the 30+ years of functional programming
> experience, it continues the very well established tradition. 

Ultimate in what sense? The number of extension elements? I don't think the
one-size-fits-all concept is a goal in it self here. It seems to me that you
are seeking the minimal extension in a theoretical sense. I think it's more
important to find a solution that is convenient and comprehendible from the user
perspective. Also, regardless of its 30+ years or so, the concept of lambda expressions
hasn't yet spred to the masses, and I doubt it ever will. So what seems to be a neat
concept in syntax and theory, can be a great obstacle for many users.

> > I'm not sure why the syntax you're proposing is different from the
> > "exsl:function" syntax that's been raging on this list for the last few
> > weeks.
> > 
> 
> I am *very* glad that the EXSL initiative takes place. However, if I
> were asked to design a feature similar to <exsl:function>, I would do it
> another way.

In fact your xsl:define has almost exactly the same content model as my first suggestion
of a cleaner exsl:function (you can find it somewhere in the archives). The only difference
is that I allowed xsl:variables to appear after the xsl:params. Many of the comments to
that proposal indicated that it was far too restricted. Even though I didn't think it was
restricted from a functional point of view, I discovered that in practice, when implementing
example functions, the approach was inconvenient. And this was even after adding a conditional
construct to XPath! So I gave it a couple of more thoughts, and the result was FXPath as
it stands now, which I find very convenient, but then I'm biased :-). I even streched it so far that I did an
test implementation in SAXON (http://www.pantor.com/fxpath/saxon.html) to get a feeling
of the complexity from the implementors point of view.

Now, your proposal contains another side that is different from both EXSLT and FXPath,
the ability to use functions as first class objects. Being able to pass functions as parameters,
and return them from functions is a very powerful thing. And as I said in my previous reply,
this is one of the things I have mind for further development of FXPath. Though I wouldn't
use it as the primary vehicle for extension functions in XSLT for the reasons mentioned
above. More over, to get the full power out of such a construct, I would treat
the functions as closures with access to all the variable bindings visible at the point of definition.
Since the first argument to your xsl:call is an RTF you had to limit the variable bindings to
parameters and global variables. Also, using an RTF for the first argument adds undesirable
flexibility in my opinion. It means that you can dynamically construct the code of the function.
This is much like an evaluate function for XPath. There are situations where such flexibility
is desired, however, it better be separated from the standard calling mechanism.

Cheers,

</David>

David Rosenborg
Pantor Engineering AB



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