- From: <bugzilla@jessica.w3.org>
- Date: Mon, 08 Dec 2014 16:27:46 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27537 Bug ID: 27537 Summary: [XP31] Sequence on lhs of arrow operator Product: XPath / XQuery / XSLT Version: Last Call drafts Hardware: PC OS: All Status: NEW Severity: normal Priority: P2 Component: XPath 3.1 Assignee: jonathan.robie@gmail.com Reporter: mike@saxonica.com QA Contact: public-qt-comments@w3.org Botond Biró raised this on public-qt-comments: What is the expected behavior if the arrow postfix operator is applied to a sequence containing more than one item? Does the semantic equivalence "$seq=>$f(…) is the same as $f( $seq, … )" also hold when count($seq) != 1? ex, ( 1, 2, 3 ) => avg() or ()=>count() In the last call working draft the wording for arrow postfix definition implies that a [single] item is expected, but don’t see why or if this restriction would be necessary. “[Definition: An arrow operator is a postfix operator that applies a function to an item, using the item as the first argument to the function.] If $i is an item and f() is a function, then $i=>f() is equivalent to f($i), and $i=>f($j) is equivalent to f($i, $j).” If the single restriction doesn't apply, then I suggest modifying the definition to reflect this. And a question related to operator precedence: currently it is not possible to use a node selection on the lhs of an arrow operator without wrapping it with extra parenthesis: $DAYS//@From => max() - syntax error ($DAYS//@From) => max() - ok is it planned for the arrow operator to be moved above the step expression(i.e. get lower precedence) so that one can use a node selection => without the need of the extra parenthesis? MHK comment: I don't think there was ever any intention to restrict the LHS to a single item. The definition should be: [Definition: An arrow operator is a postfix operator that applies a function to an value, using the value as the first argument to the function.] If $s is a sequence and f() is a function, then $s=>f() is equivalent to f($i), and $s=>f($j) is equivalent to f($s, $j). As regards the operator precedence, I can see the case for making /section/para => count() mean count(/section/para) One can also see a case for richer expressions on the right, e.g. $input => $function-lib?cosine For an example of a surprise coming from the current rules, consider -1 => abs() which returns -1. There would seem to be a case for decoupling the arrow operator from the Postfix construct, and having [95] CastExpr ::= ArrowExpr ( "cast" "as" SingleType )? [NN] ArrowExpr ::= UnaryExpr "==>" UnaryExpr -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Monday, 8 December 2014 16:27:48 UTC