From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-3.1 required=3.0 tests=BAYES_00,DKIM_ADSP_CUSTOM_MED, FORGED_GMAIL_RCVD,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id 0DA301F461 for ; Fri, 17 May 2019 19:53:35 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id 5753D1140BA; Sat, 18 May 2019 04:53:29 +0900 (JST) Received: from o1678948x4.outbound-mail.sendgrid.net (o1678948x4.outbound-mail.sendgrid.net [167.89.48.4]) by neon.ruby-lang.org (Postfix) with ESMTPS id 929AD114081 for ; Sat, 18 May 2019 04:53:27 +0900 (JST) Received: by filter0138p3mdw1.sendgrid.net with SMTP id filter0138p3mdw1-15924-5CDF1137-22 2019-05-17 19:53:27.84718702 +0000 UTC m=+162875.652234691 Received: from herokuapp.com (unknown [3.95.247.207]) by ismtpd0005p1iad2.sendgrid.net (SG) with ESMTP id CdLFVfk6R-yvBoKkptc-kw for ; Fri, 17 May 2019 19:53:27.745 +0000 (UTC) Date: Fri, 17 May 2019 19:53:28 +0000 (UTC) From: eregontp@gmail.com Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 68186 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 14844 X-Redmine-Issue-Author: rmosolgo X-Redmine-Issue-Assignee: yui-knk X-Redmine-Sender: Eregon X-Mailer: Redmine X-Redmine-Host: bugs.ruby-lang.org X-Redmine-Site: Ruby Issue Tracking System X-Auto-Response-Suppress: All Auto-Submitted: auto-generated X-SG-EID: =?us-ascii?Q?KippOI8ZHtTweq7XfQzW93937kJ4QNWwSBuHnaMEcr1TQK=2Fy1qjpsdgSqIINhh?= =?us-ascii?Q?thDfIHvrAFIdj44V6qTX9f9FxNNNWHBkWfWXXcw?= =?us-ascii?Q?cnaIxFgD3bucCRa5wiJtjQMptze7ImdEMKhoKYq?= =?us-ascii?Q?q=2FiqaCmaDWXKwOYM=2F1y+milWkNQ8e=2FSHPwazDOv?= =?us-ascii?Q?PrMG8v3T9rlpAmCAJeWkIjiR6aG+O0sR=2F6A=3D=3D?= To: ruby-core@ruby-lang.org X-ML-Name: ruby-core X-Mail-Count: 92703 Subject: [ruby-core:92703] [Ruby trunk Feature#14844] Future of RubyVM::AST? X-BeenThere: ruby-core@ruby-lang.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Ruby developers List-Id: Ruby developers List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ruby-core-bounces@ruby-lang.org Sender: "ruby-core" 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/