Subject: Higher-order function support as means to reduce the "standard" operators/functions. (Was(Re: [xsl] Re: . in for)) From: Dimitre Novatchev <dnovatchev@xxxxxxxxx> Date: Sat, 5 Jan 2002 12:16:47 -0800 (PST) |
--- Jeni Tennison <jeni@xxxxxxxxxxxxxxxx> wrote: [snip] > It would also prevent the nice 'piping' aspect of a mapping operator. > Rather than: > > $coordinates -> (. * 2) > -> if (position() mod 2) then . + 50 else . > > You would have, I think: > > ( if (position() mod 2) then a + 50 else a | > a -> ( (b * 2) | b -> $coordinates ) > I see. Such an operator would really be nice, but then other operators such as functional composition and sequence concatenation would also be nice, then maybe still others... What is interesting is that in case XPath 2.0 provided support for higher-order functions, the programmers would not depend on the language designers and would not have to beg them to implement one or another new operator. It would be possible first to construct the 'map' function itself almost from scratch like this (the following definitions are in Haskell): map f = foldl ((:).f ) [ ] and I have already this function implemented in XSLT 1.0 using generic templates. Then one could define a multiMap function like this: multiMap :: [a] -> [a -> a] -> [a] multiMap xs fs = foldr map xs fs where xs is the initial argument-list and fs is a list of mapping functions that will be applied in consecutive mapping operations on the list xs, from the last function to the first. Thus: multiMap [1, 2, 3] [(1+), (2*), (5+)] produces: [13,15,17] that is [(1 + 5)*2 +1, (2 + 5)*2 +1, (3 + 5)*2 +1] A shorter and equivalent definition of multiMap is: multiMap = foldr map In case we want the list of functions to be applied starting from the first one, rather than from the last function in the list, then the following definition will be used: multiMap xs fs = foldl (flip map) xs fs or more briefly: multiMap = foldl (flip map) Now we'll have: multiMap [1, 2, 3] [(1+), (2*), (5+)] produces: [9,11,13] that is [(1 + 1)*2 + 5, (2 + 1)*2 + 5, (3 + 1)*2 + 5] Then your piping example will be expressed like this: multiMap($coordinates, ($pF1, $pF2 ) ) where $pF1 and $pF2 are references to templates, which respectively implement: (. * 2) and if (position() mod 2) then . + 50 else . Or probably, in case XPath 2.0 supported higher-order functions, then expressions could be passed as parameters. Then we could even be able to wite: multiMap($coordinates, ((. *2), (if (position() mod 2) then . + 50 else .) ) ) This is equivalent to the expression using your proposed mapping operator, while the first variant/notation is imediately implementable in XSLT 1.0. To summarize: 1. map() and many other general list-processing, tree-processing, function-processing. ... etc. functions can be immediately implemented/used based on template references/generic templates even now in XSLT 1.0. 2. In case higher-order functions will be supported in XPath 2.0, then the language will not have to implement numerous functions and operators as "standard" before their usability has been really proven. This will offload the language and make it more elegant (small is beautiful), while at the same time providing powerful means for the users to create multitude of functions by passing functions as parameters for other functions or as the result of other functions. Libraries of user-created functions will emerge and there will not be any strong need to ask the language designers for this or that "standard" function. 3. Someone noted that already there were no more spare characters to be used for operators. At the same time people are wondering that there are multiple ways (different functions, operators, language constructs) to do almost the same thing, and this may be confusing and lead to errors. Based on my brief example it is clear, that the standard language can be kept small, allowing at the same time any desired functionality to be easily implemented by programmers, based on higher-order function support. Cheers, Dimitre Novatchev. __________________________________________________ Do You Yahoo!? Send FREE video emails in Yahoo! Mail! http://promo.yahoo.com/videomail/ XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Re: . in for, Jeni Tennison | Thread | RE: Higher-order function support a, Michael Kay |
Re: [xsl] Re: . in for, Daniel Veillard | Date | RE: Where is the benefit ? (Was : R, Kevin Jones |
Month |