This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Functional programming in XSLT
- To: xsl-list at lists dot mulberrytech dot com
- Subject: Re: [xsl] Functional programming in XSLT
- From: Alexey Gokhberg <alexei at bluewin dot ch>
- Date: Wed, 14 Mar 2001 12:13:27 +0100
- References: <000a01c0aadd$8be66380$0100007f@oemcomputer>
- Reply-To: xsl-list at lists dot mulberrytech dot com
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