- 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