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?
相关问题
- XML - XSLT - document() function inside count() fu
- Relation between Function1 and Reader Monad
- Using XSLT to select after EACH instance in a stri
- scala passing function with underscore produces a
- XSLT open other xml files
相关文章
- Is there something like the threading macro from C
- Learning F#: What books using other programming la
- Creating a list of functions using a loop in R
- xslt localization
- When to use interfaces, and when to use higher ord
- Functors in Ocaml
- Java Lambda Referencing Enclosing Object: Replace
- Are 'currying' and 'composition' t
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 :-)
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:
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.
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 withsaxon:call()
.Saxon-B has similar functionality with the pairing of
saxon:expression()
andsaxon:eval()
. The difference is thatsaxon:expression()
takes any XPath expression, andsaxon:eval()
evaluates it, whereassaxon:function()
takes the name of a function whichsaxon:call()
calls.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
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.
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!