Re: ripper on array access operation

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

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.

Whew. I'm only responding because you asked such direct questions :) As 
I've said, RubyParser works better for me, while Ripper is a bit more 
difficult to manage. Clearly you needed more information about the 
program, so Ripper made sense to use. As you have pointed out before, 
Ripper has its own issues. There are use cases for either one depending 
on what your needs are. If Ripper were available for 1.8, I might have 
used it instead.

-Justin