This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
RE: mapping (Was: Re: Re: . in for)
- From: naha at ai dot mit dot edu
- To: xsl-list at lists dot mulberrytech dot com
- Date: Wed, 09 Jan 2002 14:49:09 -0500 (EST)
- Subject: RE: mapping (Was: Re: [xsl] Re: . in for)
- References: <3C3C481C.C5001B23@zkb.ch>
- Reply-to: xsl-list at lists dot mulberrytech dot com
Quoting Joerg Pietschmann <joerg.pietschmann@zkb.ch>:
[...]
> Another possibility is having map() take a variable number of
> arguments,
> the first is the function, all following sequences which supply the
> parameters in parallel (like in most LISP variants)
>
>
select="map(my:grumbulation,stuff-children,my:build-sequence($grumbulation-value,count(stuff-children)))"
>
> Specifying the exact behaviour of the map function, especially for
> the cases of having sequences of different length supplied, is tedious
> but it should be possible to lift it almost literally from some LISP
> specification.
[finally something I'm qualified to comment on]
In CommonLisp mapping termincates as soon as one of the input sequences is
exhausted, so the output sequence will be as long as the shortest argument
sequence. See
http://www.xanalys.com/software_tools/reference/HyperSpec/Body/fun_mapccm_ma_istcm_mapcon.html#mapcar
> Oh no, i just saw the problem with using QNames for passing functions:
> they are already XPath expressions for accessing nodes :-/
> Let's have a function for converting Strings which are actually QNames
> of functions to function objects, like the well known LISP 'function
> (I mean as in (mapcar (function cdr) list) ).
> This means writing
> select="map(xf:funref('my:grumbulation'),$departments)"
> The argument of such a generic function object constructor could be
> made
> a literal for the sake of optimizations. I think however some people
> will
> consider the standard crippled if they can't read their function names
> from the source XML :-)
Would it be fair to disambiguate the QName by context? This would impose
the constraint that one couldn't use the same QName to name both a function
and an infoset node. Perhaps the disambiguation could be done at the
namespace level rather than at the QName level, so for a QName to name a
function it would have to be in a namespace that was declared to be one
containing function names. This is admittedly a bit of a kludge, but a
fairly workable one, I would think.
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list