--0016363ba6e896af8204848a353c
Content-Type: text/plain; charset=ISO-8859-1

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

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.

--0016363ba6e896af8204848a353c
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div class="gmail_quote">On 18 April 2010 23:46, Caleb Clausen <span dir="ltr">&lt;vikkous / gmail.com&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">On 4/18/10, Kornelius Kalnbach &lt;murphy / rubychan.de&gt; wrote:<br>
&gt; On 18.04.10 16:10, Benoit Daloze wrote:<br>
</div><div class="im">&gt;&gt; If there is more spaces at left than rightf the &#39;operator&#39; it should<br>
&gt;&gt; be a method.<br>
&gt;&gt; p % [a] # operator<br>
&gt;&gt; p %[a] # method<br>
&gt;&gt; p%[a] # operator<br>
&gt; +1. I think this rule should ony distinguish &quot;no space&quot; and &quot;one ore<br>
&gt; more spaces&quot;. Otherwise, we&#39;d have to start counting spaces. Fun for the<br>
&gt; next obfuscation contest.<br>
<br>
</div>I agree as well that it should be presence/absence of spaces, not theumber.<br>
While we&#39;re at it, let&#39;s not forget about this case:<br></blockquote><div>/div><div>Me too, I just thought as one or zero space, so basically presence/absence<br>/div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

p% [a] # operator<br>
<br>
The governing rule is what I call the before-but-not-after rule:<br>
<br>
Ambiguous operators are treated as (the beginning of) literals instead<br>
of operators if they follow what looks like a method call and there is<br>
whitespace before but not after them.<br></blockquote><div>/div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left:px solid rgb(204, 204, 204); padding-left: 1ex;">
What nobu has done is in keeping with that rule, just refining what<br>
&#39;looks like a method call&#39; a little, in the case of variable/method<br>
collisions.<br>
<div class="im"><br>
&gt;&gt; This idea is valid only if the right part is a literal expression:<br>
&gt;&gt; p % a , p %a , p%a are in all cases operators.<br>
&gt; I&#39;m not sure whether the lexer can look ahead this far.<br>
<br>
</div>Yeah, at first glance, I&#39;d say that trying to determine what<br>
(nonwhitespace) token follows the operator is too much extra<br>
complication. My implementation just looks at the next character to<br>
see if it is whitespace. Judging by its behavior, that&#39;s what MRI does<br>
as well.<br><div class="im">
&gt;&gt; Would it be possible to implement a rule like that:<br>
&gt;&gt; &quot;if more spaces at left than right and right is a literal expression,<br>
&gt;&gt; consider left as a method&quot; (instead of always as an operator)<br>
&gt; As far as I understood nobus patch, it does exactly that.<br>
<br>
</div>For the most part, this rule is already implemented by ruby. Murphy<br>
and I have expressed our two reservations above. I prefer the<br>
before-but-not-after rule as I formulated above; do you have any<br>
quibbles with that, Benoit?<br><div class="im"></div></blockquote><div><br>Not as far as I understand your rule, the main idea is the same.<br>/div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div class="im">
&gt;&gt; This change is only an improvement to my opinion, so I don&#39;t see when it<br>
&gt;&gt; can cause problems.<br>
&gt; Incompatibility is a problem. I wouldn&#39;t start to write code that&#39;s only<br>
&gt; valid in Ruby 1.9.2, because 1.8.7 is so much more popular.<br>
&gt;<br>
&gt; But it doesn&#39;t seem to be a problem yet. I checked the syntax of 20K<br>
&gt; Ruby files in 300 gems before and after nobu&#39;s patch. The diff is<br>
&gt; attached. Only obscure code (like Caleb&#39;s rubylexer examples ;) and ERB<br>
&gt; templates (which are invalid anyway) seem to be hit.<br>
<br>
</div>Ha! glad to see my testcases made the language squeak again. Thanks<br>
for testing that, murphy. Looks like from that evidence there&#39;s little<br>
enough cause to worry about creating incompatibilities; I certainly am<br>
not concerned about any of the code I wrote.<br>
<div class="im"><br>
&gt; But it might not be a good idea to change it suddenly in 1.9.2.<br>
<br>
</div>Yeah, isn&#39;t there supposed to be a feature freeze right now?<br>
</blockquote></div><br>Let me be happy my Ruby works better with that :)<br><br>Seriously, what is done and good should be kept, at anytime, if accepted.<br><br>Thanks for interesting discussion on this thread,<br><br>Regards,<br>
B.D.<br>

--0016363ba6e896af8204848a353c--