From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS4713 221.184.0.0/13 X-Spam-Status: No, score=-3.2 required=3.0 tests=AWL,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.1 Received: from neon.ruby-lang.org (neon.ruby-lang.org [221.186.184.75]) by dcvr.yhbt.net (Postfix) with ESMTP id ABC001F403 for ; Tue, 12 Jun 2018 15:43:06 +0000 (UTC) Received: from neon.ruby-lang.org (localhost [IPv6:::1]) by neon.ruby-lang.org (Postfix) with ESMTP id CA021121791; Wed, 13 Jun 2018 00:43:02 +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 8E41E12178F for ; Wed, 13 Jun 2018 00:42:59 +0900 (JST) Received: by filter0061p3mdw1.sendgrid.net with SMTP id filter0061p3mdw1-7553-5B1FE9FF-F 2018-06-12 15:42:55.37645649 +0000 UTC Received: from herokuapp.com (ec2-54-205-177-240.compute-1.amazonaws.com [54.205.177.240]) by ismtpd0010p1iad1.sendgrid.net (SG) with ESMTP id BhFTG_HDQzy4RwUfvnZBxQ for ; Tue, 12 Jun 2018 15:42:55.316 +0000 (UTC) Date: Tue, 12 Jun 2018 15:42:56 +0000 (UTC) From: shevegen@gmail.com To: ruby-core@ruby-lang.org Message-ID: References: Mime-Version: 1.0 X-Redmine-MailingListIntegration-Message-Ids: 62856 X-Redmine-Project: ruby-trunk X-Redmine-Issue-Id: 14844 X-Redmine-Issue-Author: rmosolgo X-Redmine-Sender: shevegen 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: ync6xU2WACa70kv/Ymy4QrNMhiuLXJG8OTL2vJD1yS75HpMlSnqXvXkFyASWC3sZROjrlukRpaUqhZ yznU8WInXX+T80tbdYb8XT3YVYph3swp3nxHpewgp/XK1k7O73IBBLnqvu7A5JU+8dciGtGuUfiZjQ R1goBzu43X3Ci2gOI5A+rfuy0jimElPJ/DB9NpugforgN7cyePWbza31XQ== X-ML-Name: ruby-core X-Mail-Count: 87481 Subject: [ruby-core:87481] [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 shevegen (Robert A. Heiler). Just two short comments from me, so that I do not expand the issue request/question too much. (1) I would like to suggest to you to consider adding your question to the upcoming developer meeting; it may be best to have the core team and other core contributors comment on it, including matz and (based on RubyVM I think) koichi. The next upcoming meeting agenda should be compiled here: https://bugs.ruby-lang.org/issues/14769 But again, this is just a suggestion from me - it is your issue/question so of course you should decide. :) (2) The other thing is, and I may be wrong, but I think there have been quite a few introspection-related extensions to ruby in general, by different ruby hackers/developers/core contributors. You mentioned RubyVM but I think there are a few more examples; Martin in regards to unicode and ... I think the regex engine (I forgot the particular issue but I remember it was somehow related to being able to tweak more within the regex engine). MJIT is also a bit related to more introspection, at the least indirectly, if we can control how much we can optimize where and how, at the least in the future (say, past ruby 3.0). matz mentioned one requirement/goal for mruby is in regards to systems that are constrained, but with MJIT we may be able to perhaps control more optimizations when it comes to systems that have more RAM/cpu power/cores and so forth. So, I may be wrong, but I think several changes in ruby are to some extent related to more introspection. (The MJIT author blogged about this too, I think ... something about inline-C or like that? I forgot the details right now, sorry.) Of course it may be best to have koichi comment on relevant parts of your question such as "a lot more information in the C structures that we could expose" (and whether matz is fine with this; I think matz is fine with it but it may be best to ask this in regards to the developer meeting altogether). I personally love introspection. PS: Actually, I just remembered one more change that is a bit related to introspection, at https://github.com/ruby/ruby/blob/trunk/NEWS added Binding#source_location. [Feature #14230] While eval() could be used, I think Binding#source_location has a nicer API. ---------------------------------------- Feature #14844: Future of RubyVM::AST? https://bugs.ruby-lang.org/issues/14844#change-72474 * Author: rmosolgo (Robert Mosolgo) * Status: Open * Priority: Normal * Assignee: * 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/