Subject: Re: [xsl] Functional programming in XSLT From: "David Rosenborg" <david.rosenborg@xxxxxxxxxx> Date: Wed, 14 Mar 2001 16:04:18 +0100 |
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
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Functional programming in, Jeni Tennison | Thread | Re: [xsl] Functional programming in, Alexey Gokhberg |
RE: [xsl] Problem with keys in for-, Don Bruey | Date | RE: [xsl] RE: multi-phase transform, Michael Kay |
Month |