Re: [xsl] Functional programming in XSLT

Subject: Re: [xsl] Functional programming in XSLT
From: Alexey Gokhberg <alexei@xxxxxxxxxx>
Date: Fri, 16 Mar 2001 13:07:55 +0100
Hello, David

David Rosenborg wrote:
> 
> 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. 

My goal is keeping the set of added features as small as possible, and
making the entire set of features (that is, core XSLT and few
extensions) orthogonal. The approach based xsl:lambda (now fxsl:lambda()
function) is ultimate in this sense - it provides support for the entire
class of requirements by combining fxsl:function/fxsl:lambda with the
existing XSLT features.

> It seems to me that you
> are seeking the minimal extension in a theoretical sense. 

You are right. At this phase, FXSLT as a purely theoretical research
(although this specification may be implemented in the future release of
Unicorn XSLT Processor). I am looking for a way of implementing
functional programming in XSLT based on the principles proclaimed in the
preamble to the revised FXSLT proposal. The usability study is another
matter. I will start it once I will obtain the stable FXSLT
specification.

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

This is discussable. I would postpone the discussion for a while, until
I will obtain enough material for the usability study mentioned above.
Now I would like to make just few comments:

First, the concept of the functional programming itself hasn't probably
yet spred to the masses, and using it can be a great obstacle for many
XSLT users. From the user perspective, the ultimate collection of XSLT
extensions might contain just 3 extension elements (all implemented by
SAXON):

saxon:assign
saxon:while
saxon:function

(Personally, I would also add something like "unicorn:array" to support
dynamic arrays of arbitrary values, with the appropriate set of arre
extension functions - this will surely knock out every fan of the
functional programming).

Furthermore, as I could observe, "lambda" is quite widespread, featuring
even in some modern procedural, object-oriented languages like Python
(and Python programmers are using ot quite frequently).

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

I'm well aware that I might repeat certain steps from the early FXPath
design process. My final goal is, however, building the technology based
primarily on the extension of XSLT rather than XPath, so the design as a
whole is completely different (although FXSLT and FXPath surely will
share many ideas).

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

I fully agree that:
  * more liberal access rules for variables are desirable
  * using RTF to represent lambda instances was not a successful idea
  * lambda objects should be treated as closures consisting of:
        * a function
        * a list of variable bindings

All these changes were incorporated in the revised FXSLT proposal.


Kind regards,

Alexey

----------------
Alexey Gokhberg
Unicorn Enterprises SA
http://www.unicorn-enterprises.com

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


Current Thread