Quantcast

[Bug 26889] New: Extending the arrow operator

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Bug 26889] New: Extending the arrow operator

Bugzilla from bugzilla@jessica.w3.org
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: [hidden email]
          Reporter: [hidden email]
        QA Contact: [hidden email]

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.
Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Bug 26889] Extending the arrow operator

Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26889

Michael Kay <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #1 from Michael Kay <[hidden email]> ---
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...)

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

Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Bug 26889] Extending the arrow operator

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26889

--- Comment #2 from Jonathan Robie <[hidden email]> ---
I agree with Mike Kay completely.

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

Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Bug 26889] Extending the arrow operator

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26889

C. M. Sperberg-McQueen <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #3 from C. M. Sperberg-McQueen <[hidden email]> ---
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.

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

Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Bug 26889] Extending the arrow operator

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26889

Josh Spiegel <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #4 from Josh Spiegel <[hidden email]> ---
I don't want "=>" to depend on the optional HOF feature.

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

Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Bug 26889] Extending the arrow operator

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26889

Liam R E Quin <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |[hidden email]

--- Comment #5 from Liam R E Quin <[hidden email]> ---
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.

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

Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Bug 26889] Extending the arrow operator

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26889

--- Comment #6 from Jonathan Robie <[hidden email]> ---
(In reply to Josh Spiegel from comment #4)
> I don't want "=>" to depend on the optional HOF feature.

+1

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

Loading...