This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 14152 - [F+O30] A enumerator function
Summary: [F+O30] A enumerator function
Status: RESOLVED LATER
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 3.0 (show other bugs)
Version: Working drafts
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-09-15 06:36 UTC by Vladimir Nesterovsky
Modified: 2011-10-04 16:22 UTC (History)
3 users (show)

See Also:


Attachments

Description Vladimir Nesterovsky 2011-09-15 06:36:31 UTC
I would like the WG to consider an addition of a function that turns a sequence into a enumeration of values.

Consider a function like this:
 fn:enumerator($items as item()*)  as function() as item();

alternatively, signature could be:
 fn:enumerator($items as function() as item()*)  as function() as item();
 
This function receives a sequence, and returns a function item, which upon N's call shall return N's element of the original sequence. This way, a sequence of items is turned into a function providing a enumeration of items of the sequence.
 
As an example consider two functions:
a) t:rand($seed as xs:double) as xs:double* - a function producing a random number sequence;
b) t:work($input as element()) as element() - a function that generates output from it's input, and that needs random numbers in the course of the execution.
 
t:work() may contain a code like this:
  let $rand := fn:enumerator(t:rand($seed)),
and later it can call $rand() to get a random numbers.
 
Enumerators will help to compose algorithms where one algorithm communicate with other independant algorithms, thus making code simpler. The most obvious class of enumerators are generators: ordered numbers, unique identifiers, random numbers.
 
Technically, fn:enumerator() is nondetermenistic, but its "side effect" is similar to a "side effect" of a function generate-id() from a newly created node (see bug #13747, and bug #13494).
Comment 1 Ghislain Fourny 2011-09-22 12:14:30 UTC
There might be a technical issue with the fact that there is no evaluation order in XPath 3.0 as far as I know. Even if the function item returned by fn:enumerator is annotated as non-deterministic (i.e., can return a different result for each call), if I am correct, the following query:

let $enumerator := fn:enumerator((1,2))
return ($enumerator(), $enumerator())

may lead to the result 1 2, but also to the result 2 1, which the user cannot control, as there is no constraint about the order in which the operands of the sequence expression are evaluated (there is only a spatial order for the concatenation of their results).

This function might require the XQuery Scripting WD - unless if it is okay to lose the input sequence order? Are there use cases requiring order preservation?
Comment 2 Vladimir Nesterovsky 2011-09-23 18:55:06 UTC
(In reply to comment #1)
> There might be a technical issue with the fact that there is no evaluation
> order in XPath 3.0 as far as I know. Even if the function item returned by
> fn:enumerator is annotated as non-deterministic (i.e., can return a different
> result for each call), if I am correct, the following query:
> ...

1. More correct definition of the enumerator function should be:
  fn:enumerator($items as item()*) as function() as item()?;

fn:enumerator() returns a function item (which is non-determenistic) that returns optional item.

2. According to my reading of XQuery 3.0 WD (3.9.2 For Clause), and XPath 3.0 WD (3.8 For Expressions) one may write a code like a following to avoid the issue you're pointing to:

let $enumerator := fn:enumerator((1,2)) return
for $v1 in $enumerator(), $v2 in $enumerator() return ($v1, $v2)

> Are there use cases requiring order preservation?

I think such use cases do exist.
Comment 3 Jonathan Robie 2011-10-04 16:22:51 UTC
Hi Vladimir,

This doesn't fit in our work for XQuery 3.0, we would like to examine this in later versions, and consider functional approaches.

In the meantime, any use cases or thoughts that would help us in a future design are welcome - please just append them here without reopening the issue.

Jonathan

(This reflects a decision by both Working Groups in today's telcon.)