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

[eregontp@gmail.com]

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


mame (Yusuke Endoh) wrote:
> Eregon (Benoit Daloze) wrote:
> > Could you or @yui-knk propose a description to include in the documentation, summarizing what was said?
> 
> I think that it is stated very clearly in the doc of RubyVM module.

I think that is not enough, because when people look at the documentation of RubyVM::AbstractSyntaxTree,
they don't necessarily look at the documentation of every parent module.
In fact, I find this relation rather unclear (does documentation of a parent module apply to a nested module), and for instance RubyVM::InstructionSequence is used in bootsnap
and that doesn't fit in "debugging, prototyping, and research" so much.
In my PR to clarify the purpose of RubyVM (https://github.com/ruby/ruby/pull/2113/files), I repeated everywhere that RubyVM is MRI-specific and I think we should do the same to say all of these are experimental.
Maybe we can do this with "As part of RubyVM, this module is MRI-specific and experimental".

Most importantly, I would like to see some discussion on when to use RubyVM::AbstractSyntaxTree instead of Ripper or the parser gem in the documentation.
This seems extremely important to me for people looking at RubyVM::AbstractSyntaxTree.
This is I think what we must address the most urgently for RubyVM::AbstractSyntaxTree.

> I have no strong opinion, but am a bit negative. I'm afraid if making it too useful may wrongly attract casual users.

There are already many usages of RubyVM::AbstractSyntaxTree, and yet I think almost none of them is aware of the pitfalls discussed here.
I think there is no good way to prevent users to use available features.
IMHO the only way is not having the feature, or not by default.
Maybe this is what should have happened for RubyVM::AbstractSyntaxTree: be behind a `./configure` flag, disabled by default until it's ready to be used by Rubyists at large.

I think accessing by name is what would allow RubyVM::AbstractSyntaxTree to evolve in a compatible way.
Without that, I think almost every AST or parser change will break users of RubyVM::AbstractSyntaxTree.

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

* 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/