26889 2014-09-23 11:28:25 +0000 Extending the arrow operator 2014-11-20 11:32:25 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XQuery 3.1 Working drafts PC Windows NT RESOLVED WONTFIX https://www.w3.org/Bugs/Public/show_bug.cgi?id=26585 P2 normal --- 1 christian.gruen jonathan.robie andrew_coleman cmsmcq john.snelson josh.spiegel leo liam mike public-qt-comments oldest_to_newest 112011 0 christian.gruen 2014-09-23 11:28:25 +0000 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 112013 1 mike 2014-09-23 11:45:41 +0000 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...) 112017 2 jonathan.robie 2014-09-23 14:07:13 +0000 I agree with Mike Kay completely. 114185 3 cmsmcq 2014-10-28 21:35:27 +0000 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. 114186 4 josh.spiegel 2014-10-28 21:48:07 +0000 I don't want "=>" to depend on the optional HOF feature. 114187 5 liam 2014-10-28 21:48:37 +0000 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. 114188 6 jonathan.robie 2014-10-28 21:55:21 +0000 (In reply to Josh Spiegel from comment #4) > I don't want "=>" to depend on the optional HOF feature. +1 115062 7 john.snelson 2014-11-18 17:16:02 +0000 I think extra commas and question marks reduce the benefit of the arrow operator as syntactic sugar. 115205 8 andrew_coleman 2014-11-20 11:24:25 +0000 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. 115208 9 christian.gruen 2014-11-20 11:32:25 +0000 Thanks as well for the numerous comments on this proposal.