[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Functional programming in XSLT
Michael Kay wrote: > > > Alexey Gokhberg wrote: > > > > XSLT is frequently called a functional programming language. However, > > few important constructions common for functional languages > > are missing > > in XSLT. > > > > At my opinion, adding the following features to XSLT could > > make it more suitable for the functional programming. > > I went through the same thought processes myself when I introduced > saxon:function, which has led to so much (constructive) discussion on this > list recently. But I decided that full lambda expressions were over-the-top, > 95% of the requirement could be met with the concept I called "stored > expressions" in Saxon, which is essentially a lambda expression that takes > the context node as its only argument. > I am proposing xsl:lambda for the following reasons: 1. It is simple. It costs only one extension element and one extension function. 2. It is ultimate. Once xsl:lambda is introduced, there unlikely will be a need for another construction implementing similar functionality. 3. It is ortodoxal. Based on the 30+ years of functional programming experience, it continues the very well established tradition. > I'm not sure why the syntax you're proposing is different from the > "exsl:function" syntax that's been raging on this list for the last few > weeks. > I am *very* glad that the EXSL initiative takes place. However, if I were asked to design a feature similar to <exsl:function>, I would do it another way. The primary reason is that the current design of <exsl:function> does not conform, at my opinion, to the design of the mainstream XSLT constructions. As it is stated in the recent EXSL draft itself (as an "Issue"), "... This is a departure from the XSLT 1.0 processing model." Traditionally, XSLT provides two ways for obtaining and returning values: by evaluating an XPath expression and by instantiating a template. When the first way is used, the result may be of any XSLT type; when the second way is used, the result is always a result tree fragment (RTF). There is no construction in XSLT which allows direct generation of a non-RTF value as the result of a template instantiation. The representative example is <xsl:variable>: there are two mutually exclusive forms, one is expression-based, another is template-based. The current proposal for <exsl:function> does not conform to this rule. In particular, the <exsl:result> feature, with all rules governing its use, looks a little bit odd for me. The <esxl:function> (or <uxsl:define>, or any similar construction) has a lot in common with <xsl:variable>. Both are obtaining a value in some way. The <xsl:return> element from my proposal is modelled after <xsl:variable>; semantically, it is equivalent to <xsl:variable> which assigns the return value to an anonymous variable. This design is consistent with the core XSLT processing model. The only missing feature is a conditional operator in XPath (similar to the ternary operation ?: in C). This feature is badly needed to allow node-set manipulations using the expression-based form of <xsl:return> (it is well understood, that template-based form generating RTF cannot be efficiently used to process node-sets). Once the conditional operator is added to XPath, the combinaton of <xsl:lambda> and <xsl:define> features can provide, at my opinion, a solid foundation for the functional programming in XSLT. I would not insist on the name <uxsl:define>; the <xsl:function> could be a better choice (XSLT is not directly derived from LISP, and there is <xsl:variable> rather than <xsl:let> in XSLT). > The other interesting debate is whether such things are best done at the > XSLT or XPath level: Saxon does stored expressions at the XPath level, and > the FXPath proposal does user-defined functions at this level too (sorry, > don't have the URLs handy). > Sure, such debate might take place, given the bi-lingual nature of XSLT. I beleive, that both XSLT-based and XPath-based approaches could lead to adequate (although very different) solutions. Kind regards, Alexey Gokhberg Unicorn Enterprises SA 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
|