[ruby-core:92670] [Ruby trunk Feature#14844] Future of RubyVM::AST?

[eregontp@gmail.com]

Issue #14844 has been updated by Eregon (Benoit Daloze).

Assignee set to yui-knk (Kaneko Yuichiro)

There was some discussion on Twitter about RubyVM::AbstractSyntaxTree, however so far no answer from its maintainers:
https://twitter.com/eregontp/status/1125314952368218112

It seems clear RubyVM::AbstractSyntaxTree is not for serious use with the current API.
I think the fact it's in core sounds like it's the new "blessed" AST for Ruby,
but it's not that, it's experimental, cannot evolve without breaking code (see above) and rather impractical currently.

What are the advantages over Ripper for instance, which is available on other Ruby implementations?
@mame @yui-knk In which situations should RubyVM::AST be used instead of Ripper? Can you give examples?

So, could we make it much clearer what RubyVM::AST is intended for, in the documentation?
Very few people know that long class names mean "experimental", I believe we need something more explicit in the documentation.
Also, long class names are obviously not very efficient to tell people not to use except for intended cases.

----------------------------------------
Feature #14844: Future of RubyVM::AST? 
https://bugs.ruby-lang.org/issues/14844#change-78033

* Author: rmosolgo (Robert Mosolgo)
* Status: Open
* Priority: Normal
* Assignee: yui-knk (Kaneko Yuichiro)
* Target version: 
----------------------------------------
Hi! Thanks for all your great work on the Ruby language. 

I saw the new RubyVM::AST module in 2.6.0-preview2 and I quickly went to try it out. 

I'd love to have a well-documented, user-friendly way to parse and manipulate Ruby code using the Ruby standard library, so I'm pretty excited to try it out. (I've been trying to learn Ripper recently, too: https://ripper-preview.herokuapp.com/, https://rmosolgo.github.io/ripper_events/ .)

Based on my exploration, I opened a small PR on GitHub with some documentation: https://github.com/ruby/ruby/pull/1888

I'm curious though, are there future plans for this module? For example, we might: 

- Add more details about each node (for example, we could expose the names of identifiers and operators through the node classes)
- Document each node type 

I see there is a lot more information in the C structures that we could expose, and I'm interested to help out if it's valuable. What do you think? 



-- 
https://bugs.ruby-lang.org/