Re: [xsl] Functional programming in XSLT

[Alexey Gokhberg <alexei@xxxxxxxxxx>]

Michael Kay wrote:

> 
> > Alexey Gokhberg wrote:
> >
> > XSLT is frequently called a functional programming language. However,
> > few important constructions common for functional languages
> > are missing
> > in XSLT.
> >
> > At my opinion, adding the following features to XSLT could
> > make it more suitable for the functional programming.
> 

> I went through the same thought processes myself when I introduced
> saxon:function, which has led to so much (constructive) discussion on this
> list recently. But I decided that full lambda expressions were over-the-top,
> 95% of the requirement could be met with the concept I called "stored
> expressions" in Saxon, which is essentially a lambda expression that takes
> the context node as its only argument.
> 

I am proposing xsl:lambda for the following reasons:

1. It is simple. It costs only one extension element and one extension
function.

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.

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

The primary reason is that the current design of <exsl:function> does
not conform, at my opinion, to the design of the mainstream XSLT
constructions. As it is stated in the recent EXSL draft itself (as an
"Issue"), 

"... This is a departure from the XSLT 1.0 processing model."

Traditionally, XSLT provides two ways for obtaining and returning
values: by evaluating an XPath expression and by instantiating a
template. When the first way is used, the result may be of any XSLT
type; when the second way is used, the result is always a result tree
fragment (RTF). There is no construction in XSLT which allows direct
generation of a non-RTF value as the result of a template instantiation.

The representative example is <xsl:variable>: there are two mutually
exclusive forms, one is expression-based, another is template-based.

The current proposal for <exsl:function> does not conform to this rule.
In particular, the <exsl:result> feature, with all rules governing its
use, looks a little bit odd for me.

The <esxl:function> (or <uxsl:define>, or any similar construction) has
a lot in common with <xsl:variable>. Both are obtaining a value in some
way. The <xsl:return> element from my proposal is modelled after
<xsl:variable>; semantically, it is equivalent to <xsl:variable> which
assigns the return value to an anonymous variable.

This design is consistent with the core XSLT processing model. The only
missing feature is a conditional operator in XPath (similar to the
ternary operation ?: in C). This feature is badly needed to allow
node-set manipulations using the expression-based form of <xsl:return>
(it is well understood, that template-based form generating RTF cannot
be efficiently used to process node-sets).

Once the conditional operator is added to XPath, the combinaton of
<xsl:lambda> and <xsl:define> features can provide, at my opinion, a
solid foundation for the functional programming in XSLT.

I would not insist on the name <uxsl:define>; the <xsl:function> could
be a better choice (XSLT is not directly derived from LISP, and there is
<xsl:variable> rather than <xsl:let> in XSLT).

> The other interesting debate is whether such things are best done at the
> XSLT or XPath level: Saxon does stored expressions at the XPath level, and
> the FXPath proposal does user-defined functions at this level too (sorry,
> don't have the URLs handy).
> 

Sure, such debate might take place, given the bi-lingual nature of XSLT.
I beleive, that both XSLT-based and XPath-based approaches could lead to
adequate (although very different) solutions.

Kind regards,

Alexey Gokhberg
Unicorn Enterprises SA

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