Is XSLT a functional programming language?

Question

Several questions about functional programming languages have got me thinking about whether XSLT is a functional programming language. If not, what features are missing? Has XSLT 2.0 shortened or closed the gap?

Melee

Eric, You would be interested to know that XSLT 3.0 is a true functional programming language. It uses XPath 3.0 in which functions are first class objects and can be passed as parameters to other functions or returned as the result of calling a function. – Ream

I saw you're excellent XML course on pluralsight – Unclassical

Answer 1

XSLT is declarative as opposed to stateful.

Although XSLT is based on functional programming ideas, it is not a full functional programming language, it lacks the ability to treat functions as a first class data type. It has elements like lazy evaluation to reduce unneeded evaluation and also the absence of explicit loops.

Like a functional language though, I would think that it can be nicely parallelized with automatic safe multi threading across several processors.

From Wikipedia on XSLT:

As a language, XSLT is influenced by functional languages, and by text-based pattern matching languages like SNOBOL and awk. Its most direct predecessor was DSSSL, a language that performed the same function for SGML that XSLT performs for XML. XSLT can also be considered as a template processor.

Here is a great site on using XSLT as a functional language with the help of FXSL. FXSL is a library that implements support for higher-order functions.

Because of FXSL I don't think that XSLT has a need to be fully functional itself. Perhaps FXSL will be included as a W3C standard in the future, but I have no evidence of this.

Goliath

@recursive: these are not loops in the imperative sense of the word. The order of execution is not guaranteed (this eases parallel implementations). I think a close analogy is that with xsl:for-each you create a projection on a set. – Newmann

@Abel: The order of the output seems to be guaranteed, and I don't see a useful distinction between the actual order of execution, and the order of the final results. That seems to be an implementation detail. – Flinn

@recursive, exactly, which is why these loops are different from loops in imperative languages. Suppose you'd have an xsl:message, which creates a side effect, it is not guaranteed how often and in what order it is called (though there were ways to enforce that). So, it's not only an implementation detail. It is, however, very much a property of functional programming. – Newmann

The great site you linked is a 404 :C – Usury

Answer 2

I am sure you guys have found this link by now :-) http://fxsl.sourceforge.net/articles/FuncProg/Functional%20Programming.html .

Well functions in XSLT are first class-citizens with some work arounds after all :-)

Gabbi

Answer 3

That is sort of how it feels when I am programming it.

XSLT is entirely based on defining functions and applying them to selected events that come down the input stream.

XSLT lets you set a variable. Functional programming does not allow functions to have side effects - and that is a biggie.

Still, writing in XSLT, one has the same "feel as working in an FP fashion. You are working with input - you are not changing it - to create output.

This is a very, very different programming model from that used when working with the DOM API. DOM does not separate input and output at all. You are handed a data structure - and you mangle it how you see fit - without hesitation, restriction, or remorse.

Suffice it to say if you like FP and the principles behind it, you will probably feel comfortable working in it. Just like experience with event driven programming - and XML itself - will make you comfortable with it as well.

If your only experience is with top-down, non event driven programs - then XSLT will be very unfamiliar, alien landscape indeed. At least at first. Growing a little experience and then coming back to XSLT when XPath expressions and event-handling are really comfortable to you will pay off handsomely.

Advisedly

Yes, XSL let's you set a variable, but it's immutable. – Strega

You're right! I stand corrected on that point. Thanks for calling attention to it. Once you set a variable value in XSLT you cannot change it. I actually ran into a bit of a problem with that once when I forgot/overlooked that. – Advisedly

You know, I think they should have made that more explicit in the language itself, because I'm sure you and I are not the only ones who falled into that. <variable> makes me think of something that varies (at run-time) - <constant> would be more accurate. In fact, I remember my experience with XSLT was awkward especially because I expected it to behave in a way that it just wasn't actually intended to, much the same a Java programmer would feel the first time he/she uses Javascript. – Strega

@CamiloMartin, it is called a variable, because it can vary depending on the context of the select-expression or the containing sequence constructor. A constant would be the same throughout a program. The confusion here is that a variable cannot be reassigned to within the same scope. But its value is definitely variable, hence the name. The inverse is true though: XSLT does not have a notion of constants (this changed in XSLT 3.0). – Newmann

@Newmann more than 4 years later but I still find XSLT mind-boggling. It's like someone designed a spaceship to mow the lawn. – Strega

@camilo, it typically takes half a day with a good instructor or interactive course to learn the basics, but without it, given the unusual syntax, trial and error approach may lead to a lot of frustration. Not sure about the 'spaceship' analogy, ithink it's the opposite, xslt 1.0 was so limited, xslt 2.0 improved a lot, xslt 3.0 (with xpath 3.1) made it a mature language. What used to be hard in xslt is now a breeze and expressions and constructs are much cleaner. – Newmann

Btw, my argument on varying variables in xslt: this is no different in other functional languages wrt to variables or let bindings. – Newmann

Answer 4

For the most part, what makes XSLT not a 100% functional programming language is it's inability to treat functions as a first-class data type.

There may be some others -- but that's the obvious answer.

Good luck!

Lurk

Answer 5

Saxon-SA has introduced some extension functions which make XSLT functional. You can use saxon:function() to create a function value (actually a {http://net.sf.saxon/java-type}net.sf.saxon.expr.UserFunctionCall value) which you then call with saxon:call().

Saxon-B has similar functionality with the pairing of saxon:expression() and saxon:eval(). The difference is that saxon:expression() takes any XPath expression, and saxon:eval() evaluates it, whereas saxon:function() takes the name of a function which saxon:call() calls.

Avaavadavat

fwiw this is also possible in .NET again through extension, and imho not as elegantly – Ineffable

No extensions are necessary for functional programming in XSLT and Jeni knows this well: fxsl.sf.net . FXSL -- the Functional Programming Library for XSLT has been around for more than 8 years. It is written entirely in XSLT itself. Implements almost completely the Haskell Prelude functions. – Ream

In XSLT 3.0, which comes with XPath 3.0 or 3.1, functions are now first class citizens and can be passed around as items, or invoked etc. No need for extensions anymore. – Newmann

Answer 6

That is not really an argument, since you can only declare variables, not change their values after declaration. In that sense it is declarative not imperative style, as stated in Mr Novatchev's article.

Functional programming languages like Scheme or Erlang enable you to declare variables as well, and in Haskell you can also do that:

-- function 'test' takes variable x and adds it on every element of list xs

test :: [Int] -> [Int]
test xs = map (+ x) xs
where x = 2

Gabbi