ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: eregontp@gmail.com
To: ruby-core@ruby-lang.org
Subject: [ruby-core:96231] [Ruby master Feature#14844] Future of RubyVM::AST?
Date: Sat, 14 Dec 2019 11:31:39 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-83125.20191214113139.54596e103d0e09cb@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-14844.20180612141613@ruby-lang.org

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

Status changed from Closed to Open

The ticket was closed unintentionally, I reopen it.
What's the way to mention an issue in a commit but not close it?

I clarified in the documentation that RubyVM::AbstractSyntaxTree is not stable API:
https://github.com/ruby/ruby/commit/b4b22b9278007b106fe40c0191f8dcf5e7e8c0f2
```
$ ri RubyVM::AbstractSyntaxTree

AbstractSyntaxTree provides methods to parse Ruby code into abstract
syntax trees. The nodes in the tree are instances of
RubyVM::AbstractSyntaxTree::Node.

This class is MRI specific as it exposes implementation details of the
MRI abstract syntax tree.

This class is experimental and its API is not stable, therefore it might
change without notice. As examples, the order of children nodes is not
guaranteed, the number of children nodes might change, there is no way
to access children nodes by name, etc.

If you are looking for a stable API or an API working under multiple
Ruby implementations, consider using the parser gem or
Ripper. If you would like to make RubyVM::AbstractSyntaxTree stable,
please join the discussion at https://bugs.ruby-lang.org/issues/14844.
```

If people read that documentation, it should be very clear now and they can make an informed decision on whether using RubyVM::AbstractSyntaxTree as it is is appropriate for their use case.

I think we should make RubyVM::AbstractSyntaxTree a stable longer term, but for that we need to address the mentioned issues about how to evolve the API in a compatible way when the internal AST changes.
We should also probably not have it under RubyVM (#15752).

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

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

  parent reply	other threads:[~2019-12-14 11:31 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <redmine.issue-14844.20180612141613@ruby-lang.org>
2018-06-12 14:16 ` [ruby-core:87480] [Ruby trunk Feature#14844] Future of RubyVM::AST? rdmosolgo
2018-06-12 15:42 ` [ruby-core:87481] " shevegen
2018-06-30 23:43 ` [ruby-core:87727] " samuel
2018-07-02  0:07 ` [ruby-core:87733] " samuel
2018-07-05  4:13 ` [ruby-core:87799] " samuel
2018-08-10  9:26 ` [ruby-core:88432] " bozhidar
2018-08-17  0:33 ` [ruby-core:88509] " mame
2018-08-28  1:00 ` [ruby-core:88700] " samuel
2018-12-07 11:43 ` [ruby-core:90367] " lucasbuchala
2018-12-20  4:28 ` [ruby-core:90628] " samuel
2019-01-26 11:06 ` [ruby-core:91282] " samuel
2019-04-07 19:07 ` [ruby-core:92185] " eregontp
2019-04-07 19:16 ` [ruby-core:92186] " eregontp
2019-04-18 22:26 ` [ruby-core:92323] " eregontp
2019-05-15 21:37 ` [ruby-core:92670] " eregontp
2019-05-17  1:05 ` [ruby-core:92692] " mame
2019-05-17 12:56 ` [ruby-core:92696] " eregontp
2019-05-17 16:22 ` [ruby-core:92701] " mame
2019-05-17 19:53 ` [ruby-core:92703] " eregontp
2019-05-22  7:41 ` [ruby-core:92770] " akr
2019-05-22 10:15 ` [ruby-core:92782] " eregontp
2019-12-14 11:31 ` eregontp [this message]
2019-12-14 11:50 ` [ruby-core:96232] [Ruby master " eregontp

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.ruby-lang.org/en/community/mailing-lists/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=redmine.journal-83125.20191214113139.54596e103d0e09cb@ruby-lang.org \
    --to=ruby-core@ruby-lang.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).