This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Re: Re: Re: RE: Higher-Order Functions in XPath 2.0


>terje at in-progress dot com (Terje Norderhaug) wrote:
>
>> At 7:56 PM 1/17/02, Dimitre Novatchev wrote:
>> >> > Point 3.) This essentially says there is currently no facility
>> >> > to iterate over two or more sequences in parallel rather than
>> >> > on the cartesian product. This is especially bad because
>> >> > there is no reasonable way to emulate this using the "for"
>> >> > operator. [...]
>> >
>> >Another point: How can we produce ***more than one*** sequence in
>> >parallel?
>> >
>> >For example, how to produce both:
>> >
>> >($a(i) + $b(i))-sequence
>> >and
>> >($a(i) * $b(i))-sequence
>> >
>> >In only one pass over $a and $b ?
>>
>> As there are no side effects, a smart XSL processor is already free
>> to optimize by evaluating the two using only one pass over the two
>> sequences, without requiring any special constructs in the language
>> to force parallel evaluation.
>>
>> Two things here:

[ignored smartass comment]

>2. Rather than to rely on the "smartness" of a particular XPath engine,
>it's better to have the language guarantee that this is possible.

You haven't made the case *why* the language have to guarantee that the
sequences are produced in paralell rather than as multiple passes. This
appears to be solely an efficiency issue.

Given that xpath and xsl should be usable for others than savvy
programmers, it makes sense to favor an easier understandable language that
is optimized by the xpath engine rather than a language promoting
efficiency tweaking by the developer.

I thus suggest focusing on how xpath best can describe production of
multiple sequences instead of control over whether it happens in paralell
or in more than one passes.

>What prevents such guarantee in the current WD of XPath 2.0 is the fact
>that it prohibits an item of a sequence to be a sequence itself. Also,
>there's no facility to define functions within XPath (so recursive
>definitions are not supported).
>
>In case these two factors are removed, we could have the same as
>Haskell's:
>
>partition p xs    = foldr select ([],[]) xs
>                      where select x (ts,fs) | p x       = (x:ts,fs)
>                                             | otherwise = (ts,x:fs)
>
>
>This function "partitions" a list into two lists -- one containing all
>elements that satisfy the predicate p(), the other containing the rest.
>
>The result is a pair (a sequence of exactly two elements) of the two
>lists. And, of course, they are immediately accessible through the
>functions fst() and snd() (first  and second).
>
>The partition() function comes handy when defining a sort function
>(e.g. quicksort) in a single line of code.

-- Terje <terje@in-progress.com> | Media Design in*Progress
   Software for Mac Web Professionals at <http://www.in-progress.com>
   Take Advantage of Server Side XML and XSL with Interaction 3.6!



 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]