Re: ripper on array access operation

Quoting Josh Cheek <[e-mail]>:

> On Fri, Sep 2, 2011 at 12:54 AM, Justin Collins  
> <[e-mail]>wrote:
>
>> On 09/01/2011 06:57 PM, Michael Edgar wrote:
>>
>>> On Sep 1, 2011, at 9:37 PM, Justin Collins wrote:
>>>
>>>  For what I use it for, I don't care about the exact syntax used when they
>>>> mean the same thing, and the fewer node types I need to check for, the
>>>> better.
>>>>
>>> I suspect this is actually only true at the margins, which is why parse
>>> trees are valuable and why I argue the corners RubyParser cuts are  
>>> arbitrary
>>> and silly.
>>>
>>> Would you prefer that RubyParser turn "@foo = bar" into a call to
>>> "instance_variable_set"?
>>>
>>
>> Kind of... :) But "instance_variable_set" might have a different meaning
>> than "@foo = bar". Whereas, as far as I know, "a[]" and "a.[]()" will always
>> be the same.
>>
>>
>>  Or "class A<  B; end" into a series of conditions, constant lookups,
>>> assignments, "Class.new(B)", and so on?
>>>
>>
>> I think this might be going in the other direction (but you may also be
>> correct). In "a[]" vs. "a.[]()", RubyParser makes it easier because I only
>> have to look for a call to "[]". How the call is represented in the actual
>> code is not important (to me!). If it were always valid to assume that the
>> above-mentioned conditions, lookups, etc., would mean the same as "class A <
>> B; end" then I (in my case!) would not mind if I just got back something
>> representing "class A < B; end". In other words, the reverse of what you are
>> suggesting.
>>
>>
>>  Should "class<<  foo; end" turn into "foo.singleton_class.class_**eval
>>> do.. end"?
>>>
>>> Michael Edgar
>>> [e-mail]
>>> http://carboni.ca/
>>>
>>
>> Will they always mean exactly the same thing? There are very few cases I
>> can think of where two bits of Ruby code will _always_ be the same thing,
>> because you can override nearly anything.
>>
>> Here's another case:
>>
>> ruby-1.9.2-p290 :003 > RubyParser.new.parse "!a"
>>  => s(:not, s(:call, nil, :a, s(:arglist)))
>> ruby-1.9.2-p290 :004 > RubyParser.new.parse "not a"
>>  => s(:not, s(:call, nil, :a, s(:arglist)))
>> ruby-1.9.2-p290 :005 > Ripper.sexp "!a"
>>  => [:program, [[:unary, :!, [:var_ref, [:@ident, "a", [1, 1]]]]]]
>> ruby-1.9.2-p290 :006 > Ripper.sexp "not a"
>>  => [:program, [[:unary, :not, [:var_ref, [:@ident, "a", [1, 4]]]]]]
>>
>> Again, if I want to check for a negative of "a", then with Ripper I must
>> look for (at least) two alternatives, but with RubyParser there is just one.
>> Semantically there is no difference. (There is a difference in the
>> interpretation because RubyParser doesn't know about Ruby 1.9, but that is a
>> different difference. What I mean is there is no difference between Ripper's
>> "!" and "not", because they will do the same thing.)
>>
>>
> They aren't quite the same, they bind differently:
>
> !false && false      # => false
> not false && false   # => true
>

Yes, but precedence is handled by the parser, so that difference  
doesn't matter once you have the s-expressions:

ruby-1.9.2-p290 :005 > RubyParser.new.parse "!false && false"
  => s(:and, s(:not, s(:false)), s(:false))
ruby-1.9.2-p290 :006 > RubyParser.new.parse "not false && false"
  => s(:not, s(:and, s(:false), s(:false)))
ruby-1.9.2-p290 :007 > Ripper.sexp "!false && false"
  => [:program, [[:binary, [:unary, :!, [:var_ref, [:@kw, "false", [1,  
1]]]], :"&&", [:var_ref, [:@kw, "false", [1, 10]]]]]]
ruby-1.9.2-p290 :008 > Ripper.sexp "not false && false"
  => [:program, [[:unary, :not, [:binary, [:var_ref, [:@kw, "false",  
[1, 4]]], :"&&", [:var_ref, [:@kw, "false", [1, 13]]]]]]]


>
>
>> Probably you can come up with some instances where RubyParser changes the
>> semantics of the original code it is representing, which would be a flaw in
>> RubyParser. It may or may not matter for my use case, though.
>>
>>
> I think this is the ultimate point here. You have different needs, and
> different libs to address those different needs.
>

Yes.

-Justin