[ruby-core:29604] Re: [Bug #3163] SyntaxError when using variable which is also a method in current scope with a Symbol argument

On 4/18/10, Kornelius Kalnbach <[e-mail]> wrote:
> On 18.04.10 16:10, Benoit Daloze wrote:
>> If there is more spaces at left than right of the 'operator' it should
>> be a method.
>> p % [a] # operator
>> p %[a] # method
>> p%[a] # operator
> +1. I think this rule should ony distinguish "no space" and "one ore
> more spaces". Otherwise, we'd have to start counting spaces. Fun for the
> next obfuscation contest.

I agree as well that it should be presence/absence of spaces, not the number.
While we're at it, let's not forget about this case:

p% [a] # operator

The governing rule is what I call the before-but-not-after rule:

Ambiguous operators are treated as (the beginning of) literals instead
of operators if they follow what looks like a method call and there is
whitespace before but not after them.

What nobu has done is in keeping with that rule, just refining what
'looks like a method call' a little, in the case of variable/method
collisions.

>> This idea is valid only if the right part is a literal expression:
>> p % a , p %a , p%a are in all cases operators.
> I'm not sure whether the lexer can look ahead this far.

Yeah, at first glance, I'd say that trying to determine what
(nonwhitespace) token follows the operator is too much extra
complication. My implementation just looks at the next character to
see if it is whitespace. Judging by its behavior, that's what MRI does
as well.

>> Would it be possible to implement a rule like that:
>> "if more spaces at left than right and right is a literal expression,
>> consider left as a method" (instead of always as an operator)
> As far as I understood nobus patch, it does exactly that.

For the most part, this rule is already implemented by ruby. Murphy
and I have expressed our two reservations above. I prefer the
before-but-not-after rule as I formulated above; do you have any
quibbles with that, Benoit?

>> This change is only an improvement to my opinion, so I don't see when it
>> can cause problems.
> Incompatibility is a problem. I wouldn't start to write code that's only
> valid in Ruby 1.9.2, because 1.8.7 is so much more popular.
>
> But it doesn't seem to be a problem yet. I checked the syntax of 20K
> Ruby files in 300 gems before and after nobu's patch. The diff is
> attached. Only obscure code (like Caleb's rubylexer examples ;) and ERB
> templates (which are invalid anyway) seem to be hit.

Ha! glad to see my testcases made the language squeak again. Thanks
for testing that, murphy. Looks like from that evidence there's little
enough cause to worry about creating incompatibilities; I certainly am
not concerned about any of the code I wrote.

> In addition:
>
>  p=0; p +foo
>  p=0; p -foo

Ooo, I forgot those. Thanks.

> But it might not be a good idea to change it suddenly in 1.9.2.

Yeah, isn't there supposed to be a feature freeze right now?