[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Re: Re: Re: RE: Higher-Order Functions in XPath 2.

Subject: Re: Re: Re: Re: RE: Higher-Order Functions in XPath 2.0
From: terje@xxxxxxxxxxxxxxx (Terje Norderhaug)
Date: Fri, 18 Jan 2002 12:08:33 -0800 (PST)
foldr xpath
>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@xxxxxxxxxxxxxxx> | 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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.