This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Functional programming in XSLT


Hello, David

David Rosenborg wrote:
> 
> > 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
> 
> Yes, but the difference here is that these SAXON extensions break
> totally with the XSLT processing model. So in my opinion this is
> streching things too far. I'm not saying we should turn XSLT into
> an imperative language like Java, C++, etc just because there are
> a lot of users custom to that kind of programming. But even though
> I think lambda expressions mixes better with the XSLT processing model,
> using them as the primary concept for user-defined extension functions is
> too far in the other direction.
> 

Funny enough, these three SAXON functions *do not*, at my opinion, break
the XSLT processing model in any substantial way. As the matter of fact,
I had never seen any "official" manifest, which would state that XSLT
belongs to the family of functional languages. It happened that few XSLT
experts had discovered a way for (ab)using xsl:call-template in a
functional style, and this appeared to be the only way to handle many
practically important issues with the 100% pure XSLT. These three SAXON
functions might be not conforming to the certain cultural tradition, but
not to the XSLT processing model itself.

On the other hand, nothing in the existing XSLT 1.0 design really
suggests that this is the functional language, with imperative
constructs being banned. As I had already demonstrated, few very basic
functional constructions are completely absent in XSLT, and there are no
signs that they will be officially added in the future.

Even saxon:assign does not break the present processing model - it just
*augments* it. In many languages there are distinct initialization and
assignment operations. The xsl:variable represents initiatization -
well, now we will take a next step introducing assignment with
saxon:assign.

The present XSLT specification contains (p.11.5, NOTE) some completely
undigestible description, why XSLT variables are immutable. This
description is very pragmatic (as I could interpret it, variables were
made immutable in order to make easier the life for implementors of
XSLT-aware Web browsers), and has nothing to do with the language design
phylosophy.

> Now, that said, I think that having the power of higher order functions and closures
> available can be very convenient sometimes. And also, as your latest version of
> FXSLT looks, I think it's more of an presentation issue whether you perceive
> it as lambda expression centric or just as extensions function definitions like with
> fx:define of exsl:function.
> 

In practical terms, fxsl:lambda can be very useful. It allows writing
"generic" extension functions, which can accept another extension
functions as their arguments. Therefore, some widely used functionality
like "reduce" can be coded once, being able to apply different functions
to a node-set. Consider, for example the generic function "set:reduce"
defined with two arguments

<fxsl:function name="set:reduce">
  <xsl:param name="set"/>  <!-- the node-set -->
  <xsl:param name="fun"/>  <¨-- the lambda to apply -->
  ...
</fxsl:function>

Now, having two simple extension functions num:sum(x, y) to add values
and num:max(x, y) to find maximum, you can obtain the sum and the
maximum of all nodes in a node-set with

<xsl:variable name="sum" 
    select="set:reduce($set, fxsl:lambda('num:sum'))"/>
<xsl:variable name="max" 
    select="set:reduce($set, fxsl:lambda('num:max'))"/>

Without fxsl:lambda, you will have to implement code two separate
functions, replicating the code from set:reduce each time.

Note also, that the fsxl:lambda facility is reserved for authors of XSLT
extension packages, which will likely represent the minority of XSLT
users. The majority will just export and use these packages, knowing
nothing about the implementation details.

> > 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).
> 
> But in your latest version you added the if-expression to XPath so that
> argument doesn't hold anymore. By that change you actually took the step from
> FXPath 0.0 to 0.2, so why not take one step further to 0.3? As I see it, the real
> important difference in your proposal is the function objects and closure stuff, and as
> I said in my previous post, this could be handled as an extension to FXPath.
> 

Well, I say "... based *primarily* on the extension of XSLT ..." rather
that "... based *exclusively* on the extension of XSLT ...", so adding a
single construction to XPath (which is, by the way, of general use,
having no direct relation to the FXSLT issues) does not confront to my
original statement.

Of course, if evenually I will be forced to add many more features to
XPath syntax, I might admit that I failed to find a way for XSLT-based
functional extensions. Currently I see no reasons for this.

As I had stated before, different approaches can lead to the adequate
(yet very different) solutions; FXpath and FXSLT could probably
demonstrate this.

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]