Re: [xsl] Functional programming in XSLT

["David Rosenborg" <david dot rosenborg at pantor dot com>]

Hi Alexey,

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

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.

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

Yes, you even have closures in Perl! Though, I'm not sure the every day Perl
programmer uses them that much ...

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

Cheers,

</David>

David Rosenborg
Pantor Engineering AB



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