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

On 18 April 2010 23:46, Caleb Clausen <[e-mail]> wrote:

> 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:
>

Me too, I just thought as one or zero space, so basically presence/absence


> 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?
>

Not as far as I understand your rule, the main idea is the same.


> >> 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.
>
> > 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?
>

Let me be happy my Ruby works better with that :)

Seriously, what is done and good should be kept, at anytime, if accepted.

Thanks for interesting discussion on this thread,

Regards,
B.D.