--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"><vikkous / gmail.com></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 <murphy / rubychan.de> wrote:<br> > On 18.04.10 16:10, Benoit Daloze wrote:<br> </div><div class="im">>> If there is more spaces at left than rightf the 'operator' it should<br> >> be a method.<br> >> p % [a] # operator<br> >> p %[a] # method<br> >> p%[a] # operator<br> > +1. I think this rule should ony distinguish "no space" and "one ore<br> > more spaces". Otherwise, we'd have to start counting spaces. Fun for the<br> > next obfuscation contest.<br> <br> </div>I agree as well that it should be presence/absence of spaces, not theumber.<br> While we're at it, let'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> 'looks like a method call' a little, in the case of variable/method<br> collisions.<br> <div class="im"><br> >> This idea is valid only if the right part is a literal expression:<br> >> p % a , p %a , p%a are in all cases operators.<br> > I'm not sure whether the lexer can look ahead this far.<br> <br> </div>Yeah, at first glance, I'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's what MRI does<br> as well.<br><div class="im"> >> Would it be possible to implement a rule like that:<br> >> "if more spaces at left than right and right is a literal expression,<br> >> consider left as a method" (instead of always as an operator)<br> > 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"> >> This change is only an improvement to my opinion, so I don't see when it<br> >> can cause problems.<br> > Incompatibility is a problem. I wouldn't start to write code that's only<br> > valid in Ruby 1.9.2, because 1.8.7 is so much more popular.<br> ><br> > But it doesn't seem to be a problem yet. I checked the syntax of 20K<br> > Ruby files in 300 gems before and after nobu's patch. The diff is<br> > attached. Only obscure code (like Caleb's rubylexer examples ;) and ERB<br> > 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'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> > But it might not be a good idea to change it suddenly in 1.9.2.<br> <br> </div>Yeah, isn'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--