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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format