From: Josh Cheek <josh.cheek@...>
Date: 2011-09-02T20:37:56+09:00
Subject: Re: ripper on array access operation

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

On Fri, Sep 2, 2011 at 12:54 AM, Justin Collins <justincollins@ucla.edu>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
>> adgar@carboni.ca
>> 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



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

--bcaec547c8e9ba789904abf3caa4--