[ruby-core:25968] [Feature #2131] f(not x) => syntax error

Issue #2131 has been updated by James M. Lawrence.


Yukihiro Matsumoto:
>I think you're confusing parentheses for grouping and parentheses for
>arguments.

The portion you clipped from my previous post shows that I understood
("...different meanings inside the parens...").  Again, the change in
meaning does not affect my point.

Given that I am still being misunderstood (apparently by everyone), I
will restate like this: parens have the absolute power to disambiguate
any and all cases.  When someone writes (1 + 2)*3, he is overriding
the "natural order" of precedence in order to express what he wants.

To be stepwise explicit, consider a parser that upon encountering "f("
pushes the token '(' onto a stack whose size is now n.  The only
condition which marks the end of f's arguments is the token ')' at
level n.  Arguments are separated by the ',' token at level n, (and
this is key) _even_ if the meaning inside the parens changes as a
result.

It's the explicitness of the parens which bestows the ability to
override the "natural" syntax rules.  (1 + 2)*3 has a different
meaning than 1 + 2*3 (a different situation, but the principle is the
same).

David Black:
>
>  f(class Foo; attr_accessor :x; end; Foo.new.x = 5,6)
>
>Is 6 a second argument to f, or a second argument to Foo#x= ?

Not a problem at all -- split commas at the same level of the parens.
6 is a second argument to f.  Any commas which may appear inside
'class Foo...end' are at a higher stack level and are thus not
considered.

Returning to the clipped part of my comment:
> That (a,b,c = 1,2,3) and f(a,b,c = 1,2,3) contain different meanings
> inside the parens does not really affect my argument.
>
>  [0] + (a, b, c = 1, 2, 3)   # => [0, 1, 2, 3]
>
> Whether that should mean [0, a, b, 1, 2, 3] or something else is a
> different matter.

That is, whether or not Python-like tuples deserve consideration is a
different matter.  It is _already_ the case that <expression> inside
(<expression>) can take on a different meaning when it appears as
f(<expression>).

And it is already the case that f <expression> is not interchangeable
with f(<expression>).

Ultimately it comes back to f(not x).  It feels obvious to me that it
should work as a result of the explicit parens.  I would be surprised
if no backward-compatible parsing scheme is possible which includes
this case (not necessarily one based upon the toy strategy described
above).

----------------------------------------
http://redmine.ruby-lang.org/issues/show/2131

----------------------------------------
http://redmine.ruby-lang.org