From: eregontp@... Date: 2020-08-01T13:11:01+00:00 Subject: [ruby-core:99435] [Ruby master Feature#14844] Future of RubyVM::AST? Issue #14844 has been updated by Eregon (Benoit Daloze). [RBS](https://github.com/ruby/rbs) is using `RubyVM::AbstractSyntaxTree` for `rbs prototype`. RBS is an official project under the Ruby organization, so I believe it should be able to fully work on other Ruby implementations too ([issue](https://github.com/ruby/rbs/issues/348) about this in RBS). That is impossible as long as `AbstractSyntaxTree` is under `RubyVM`, or as long as RBS uses `RubyVM::AbstractSyntaxTree` with no fallback. So, I think it is time to move `AbstractSyntaxTree` outside of RubyVM. Otherwise, other Ruby implementations will have no choice but to define `RubyVM` too, which everyone seems to agree is unwanted as RubyVM is (at least currently) meant CRuby-only. I see three ways forward: * Move `AbstractSyntaxTree` under `ExperimentalFeatures` (#15752), so it is still experimental but at least other Ruby implementations can implement it too. * Make `AbstractSyntaxTree` stable, and move it under a stable namespace (maybe just `::AbstractSyntaxTree`?) * Change the meaning of RubyVM so it is not CRuby-specific but also exists on other Ruby implementations. Many people don't know that `RubyVM` means experimental, so `ExperimentalFeatures` seems much clearer. I prefer the first option, but any of the 3 unblocks the situation (which is also explained in #15752). Can we pick one? @matz can you decide? ---------------------------------------- Feature #14844: Future of RubyVM::AST? https://bugs.ruby-lang.org/issues/14844#change-86890 * Author: rmosolgo (Robert Mosolgo) * Status: Open * Priority: Normal * Assignee: yui-knk (Kaneko Yuichiro) ---------------------------------------- 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/ Unsubscribe: