[Bug 26889] New: Extending the arrow operator

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26889

            Bug ID: 26889
           Summary: Extending the arrow operator
           Product: XPath / XQuery / XSLT
           Version: Working drafts
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XQuery 3.1
          Assignee: jonathan.robie@gmail.com
          Reporter: christian.gruen@gmail.com
        QA Contact: public-qt-comments@w3.org

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

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 23 September 2014 11:28:27 UTC