From: "James M. Lawrence" Date: 2009-10-06T22:13:29+09:00 Subject: [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 inside () can take on a different meaning when it appears as f(). And it is already the case that f is not interchangeable with f(). 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