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?
问题:
回答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.
回答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 :-)
回答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.
回答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!
回答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.
回答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