Implement ripper

[Rotonen]

http://www.ruby-doc.org/stdlib-1.9.3/libdoc/ripper/rdoc/Ripper.html

Currently not implemented.

[dbussink]

Do you know what depends on Ripper? I've taken a look but it heavily depends on MRI internals so supporting it would probably be impossible. Maybe we can make sure that the dependency gets changes, since I doubt it would really need ripper.

[hassan]

code_analyzer (https://github.com/flyerhzm/code_analyzer.git - extracted from rails_best_practices gem) requires Ripper, but I haven't investigated further yet.

[brainopia]

whitequark/parser#21 – there is a mention of code analyzer here, saying it's trivial to port the library to Parser gem which is supported across all major ruby platforms.

[dbussink]

Since we can't really solve this as Rubinius, I'm closing this issue. Hopefully other projects can use better alternatives like whitequark/parser.

[yorickpeterse]

Although Ripper is part of the Ruby standard library it's more of an internal API than something you can reliably use in your own Gems. The API is generally pretty bad, the AST it generates is borderline insane in a lot of cases, it lacks location information for certain (commonly used) nodes and the documentation isn't exactly stellar either.

Ripper is essentially a very thing Ruby layer on top of the Bison parser used by MRI. As with many parts of MRI it may look good on the outside and actually work, but the moment you start digging around you'll immediately regret that decision.

If you have a need for a Ruby parser I highly recommend that you use parser instead. Although it's still a fairly young project it's already a million times better than Ripper. To name some examples: the AST is consistent/sane, it can extract comments (and associate them with the corresponding AST nodes) and has an actual Ruby-esque API.

I've dealt with Ripper for little over a year now trying to write a linter and many times I was on the verge of losing my sanity due to Ripper. @whitequark is a very smart developer who probably knows more about all of this than he probably would want to. Seriously, use his stuff instead of Ripper.

[badosu]

Unfortunately cane (https://github.com/square/cane) uses ripper too

[saizai]

https://github.com/railsbp/rails_best_practices relies on ripper.

[brixen]

@saizai perhaps send a PR to convert to parser. /c @whitequark

[saizai]

@brixen They're choosing not to. See e.g. flyerhzm/rails_best_practices#140 flyerhzm/rails_best_practices#75

[brixen]

@saizai looks like Rubocop uses parser https://github.com/bbatsov/rubocop/blob/master/rubocop.gemspec#L42, I guess they can duke it out.

I'm happy to hear arguments for how supporting rails_best_practices adds value to Rubinius and justifies spending effort to support a very poor MRI API (ripper) when a better alternative (parser) already exists and is used by a (partial, at least, and arguable more successful) competitor of rails_best_practices. These decisions are hard to make and I'd like to know how to make them better. From my perspective, almost anything I can spend time on improving in Rubinius would be more important and valuable for its users than spending time on ripper.

[saizai]

I've got no position re ripper vs parser; don't really know either. From the sidelines, it seems like this is something about Ruby standards / introspection that would be well served by y'all collaborating on a standard that's robustly supported. Personally, I like rbx and Rails and best practices checks. I'd like to use them together, however it works out. I also think it would be good for the Ruby community in general for stuff like this to not get splintered into incompatible implementations.

[yorickpeterse]

Having spent significant time using Ripper and looking into the internals I strongly oppose supporting it. From a user perspective https://github.com/whitequark/parser is superior and more portable (it works across all Rubies). JRuby recently added support for Ripper IIRC but it took them several years to get it done (I remember asking them about it at least 2+ years ago).

The closest thing to a parser "standard" is the parser Gem (see above) itself. It's updated very frequently, compatible from Ruby 1.8 until the latest available version, has a consistent API and works across the 3 main implementations. If RubySpec was any indication of how difficult it is to standardize things I highly doubt Ripper will ever be specified properly.

Maybe one day we'll have it, but until then there are far more important things we need to sort out first.