Higher-order function support as means to reduce the "standard" operators/functions. (Was(Re: [xsl] Re: . in for))

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