On 18 April 2010 23:46, Caleb Clausen <vikkous@gmail.com>= wrote:

On 4/18/10, Kornelius Kalnbach <murphy@rubychan.de> 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:
=A0
Me too, I just thought as one or zero space, so basica= lly presence/absence
=A0
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.
=A0
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<= br> as well.
>> Would it be possible to implement a rule like that:
>> "if more spaces at left than right and right is a literal exp= ression,
>> 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.
=A0

>> This change is only an improvement to my opinion, so I don't s= ee when it
>> can cause problems.
> Incompatibility is a problem. I wouldn't start to write code that&= #39;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 2= 0K
> Ruby files in 300 gems before and after nobu's patch. The diff is<= br> > attached. Only obscure code (like Caleb's rubylexer examples ;) an= d 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<= br> 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 accept= ed.

Thanks for interesting discussion on this thread,

Regards= ,
B.D.
--0016363ba6e896af8204848a353c--