This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I decided to open a new issue for discussing Leo Wörteler's proposal on extending the arrow operator (https://www.w3.org/Bugs/Public/show_bug.cgi?id=26585). I believe that the extension would make the operator more consistent with the existing functional semantics of XQuery: Leo Wörteler, 2014-09-11 15:22:04 UTC: The current implementation of the arrow operator in the Working Draft [1] defines it as a syntactic macro: > 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)`. I think this is not very elegant and possibly confusing. Since e.g. `local:foo#0` and `local:foo#1` can be completely different functions in XQuery, it is potentially dangerous that in 1 => local:bar() => local:foo() it is not immediately obvious which of them is called. I would propose that the second argument of `=>` should instead be a function item taking one argument. Then `$arg => $f` can be translated into `$f($arg)` directly and the Spec can define it simply as equivalent to: function op:arrow-apply( $arg as item()*, $func as function(item()*) as item()* ) as item()* { $func($arg) }; As a nice bonus this also makes the feature more flexible because the argument to be inserted does not have to be the first one in the function: $file-extension => csv:get-separator() => (tokenize($line, ?))() could be written as $file-extension => csv:get-separator#1 => tokenize($line, ?) Everything that was possible before should still work when adding a "?" at the start of the ArgumentList of each right-hand side of `=>`. The example from the Spec becomes $string => upper-case(?) => normalize-unicode(?) => tokenize(?, "\s+") or (shorter and more elegant): $string => upper-case#1 => normalize-unicode#1 => tokenize(?, "\s+") In conclusion, using function items is more flexible and less confusing, and the syntactic translation scheme makes for only marginally less verbose tyntax. [1] http://www.w3.org/TR/2014/WD-xquery-31-20140424/#id-arrow-operator
I don't think this is an improvement. We've designed the function library so that in nearly all cases the first argument is in some sense the "primary input", and there's no need for it to be immediately apparent which arity of a function is being called, because all the functions with a given name do very similar things to the primary input; we would expect any well-designed function library to behave in a similar way. So adding the requirement to include the "?" placeholder in the function call on the rhs adds noise without doing anything useful. One drawback of the proposal is that it makes "=>" dependent on higher-order functions, which is (a) an optional feature, and (b) a feature that many casual users of XPath may want to steer clear of because they don't understand it. (Florent had great trouble getting the ideas across to an audience of experienced XSLT users at the summer school last week...)
I agree with Mike Kay completely.
It makes me nervous to disagree with both Michael Kay and Jonathan Robie, but I have to say that the proposal seems to me a marked improvement on the status quo. It's easier to understand, and it's easier to write.
I don't want "=>" to depend on the optional HOF feature.
Note that the current syntax (1) does not require the optional higher-order function feature; (2) parallels the foo/bar/baz() syntax in XPath, where the last step can be a function.
(In reply to Josh Spiegel from comment #4) > I don't want "=>" to depend on the optional HOF feature. +1
I think extra commas and question marks reduce the benefit of the arrow operator as syntactic sugar.
It was decided by the Working Group in the 2014-11-18 teleconference not to adopt this proposal into XQuery 3.1 for the reasons outlined in previous comments. The proposal referenced from this in bug 26585 (https://www.w3.org/Bugs/Public/show_bug.cgi?id=26585) is being considered by the Working Group separately. Many thanks for the suggestion and discussion.
Thanks as well for the numerous comments on this proposal.