ruby-core@ruby-lang.org archive (unofficial mirror)
 help / color / mirror / Atom feed
From: mame@ruby-lang.org
To: ruby-core@ruby-lang.org
Subject: [ruby-core:92692] [Ruby trunk Feature#14844] Future of RubyVM::AST?
Date: Fri, 17 May 2019 01:05:46 +0000 (UTC)	[thread overview]
Message-ID: <redmine.journal-78051.20190517010545.d1ea7f636e620ba7@ruby-lang.org> (raw)
In-Reply-To: redmine.issue-14844.20180612141613@ruby-lang.org

Issue #14844 has been updated by mame (Yusuke Endoh).


Eregon (Benoit Daloze) wrote:
> There was some discussion on Twitter about RubyVM::AbstractSyntaxTree, however so far no answer from its maintainers:
> https://twitter.com/eregontp/status/1125314952368218112

Sorry for not replying.


> 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.

You are almost correct.
"Not for serious use" and "experimental" are a bit different than what I meant, though.

I think my opinion is clear in https://bugs.ruby-lang.org/issues/14844#note-6, but I repeat it shortly.
In my opinion, the API is mainly for research and debugging purpose.  (Used on development or in ruby/test, for example.)
Also, it may be used to develop a tool that strongly depends upon a specific Ruby version.  (Used in stdlib, for example.)
It is not intended for casual use.
(Note that all the above is just for my opinion.)


> 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?

Ripper does not create an AST.  It is just a "tracer" of how the parser works.
There is `Ripper.sexp`, but it does not reproduce the details including parser-level optimization.
In theory, we may improve Ripper to be identical to the actual parser, but it is very tough.
Rather, wrapping and returning the actual AST is much easier to implement and always precise.
(Honestly, I want to remove Ripper that makes the parser code very messy.  I know it is impossible, though.)

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

* 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-05-17  1:05 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 ` mame [this message]
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 ` [ruby-core:96231] [Ruby master " eregontp
2019-12-14 11:50 ` [ruby-core:96232] " 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-78051.20190517010545.d1ea7f636e620ba7@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).