[Bug 29346] [XP31] XPath-style currying, or the arrow operator, may require a bit more specification

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

--- Comment #8 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
(In reply to Michael Kay from comment #7)
> I think that would be a poor design even if we were rethinking the design
> from scratch. But as it's attempting to add a feature after going to a
> second CR, and the feature is only cosmetic, I think it's impossible to
> justify.
I am sorry, it was not my intend to add a feature. I believe currently the spec
says zero to nothing about ArgumentPlaceholders here, so I think that leaves us
to the choice to:

a) disallow it as a syntax error
b) allow it by turning a => f(b, ?) into f(a, b, ?)
c) allow it by turning a => f(b, ?) into f(b, a)

Since the definition of the arrow operator reads:

  An arrow operator applies a function to the value of a primary expression, 
  using the value as the first argument to the function.

I think we can go either way. The first argument of the function returned by
the expression "f(b, ?)" is "?" as it returns a function with one argument.

Likewise, if you do not think in "a function" as in function item per se, your
solution applies equally well.

In terms or orthogonality, I think there is something to say for either
solution. And whether we choose (a) or (b) seems to me a matter of an arbitrary
choice, albeit that I have a preference for (b) as it appears more "natural" to
me and, since the purpose of the arrow operator is to get rid of parens, I
think in practice it will lead exactly that: less parens.

As a consequence of either (a), (b) or (c) it will always make a certain group
of expressions illegal (raising dynamic errors), that are currently legal (or
not) only by virtue of choice of implementers.

(In reply to Michael Kay from comment #6)
> We need a very strong justification to change the grammar at this stage, and
> I can't see that this is important enough. <snip />
Ok, makes sense.

> Incidentally, as defined in the spec concat#3(1,2,3) is not a static
> function call, it is a dynamic function call.
Ah, of course, thanks for pointing that out.

> If we want more orthogonality in the grammar then the top thing on my list
> would be to add VarRef on the rhs of a lookup operator. But we don't want
> minor improvements now, we want to finish.
Of course. (I didn't even realize that VarRef is not allowed there, I see now
that you have to write it as M?($varref) to be valid, assuming that's what you
meant here).

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

Received on Friday, 18 December 2015 16:55:15 UTC