[#33640] [Ruby 1.9-Bug#4136][Open] Enumerable#reject should not inherit the receiver's instance variables — Hiro Asari <redmine@...>

Bug #4136: Enumerable#reject should not inherit the receiver's instance variables

10 messages 2010/12/08

[#33667] [Ruby 1.9-Bug#4149][Open] Documentation submission: syslog standard library — mathew murphy <redmine@...>

Bug #4149: Documentation submission: syslog standard library

11 messages 2010/12/10

[#33683] [feature:trunk] Enumerable#categorize — Tanaka Akira <akr@...>

Hi.

14 messages 2010/12/12
[#33684] Re: [feature:trunk] Enumerable#categorize — "Martin J. Dst" <duerst@...> 2010/12/12

[#33687] Towards a standardized AST for Ruby code — Magnus Holm <judofyr@...>

Hey folks,

23 messages 2010/12/12
[#33688] Re: Towards a standardized AST for Ruby code — Charles Oliver Nutter <headius@...> 2010/12/12

On Sun, Dec 12, 2010 at 9:55 AM, Magnus Holm <judofyr@gmail.com> wrote:

[#33689] Re: Towards a standardized AST for Ruby code — "Haase, Konstantin" <Konstantin.Haase@...> 2010/12/12

On Dec 12, 2010, at 17:46 , Charles Oliver Nutter wrote:

[#33763] [Ruby 1.9-Bug#4168][Open] WeakRef is unsafe to use in Ruby 1.9 — Brian Durand <redmine@...>

Bug #4168: WeakRef is unsafe to use in Ruby 1.9

43 messages 2010/12/17

[#33815] trunk warnflags build issue with curb 0.7.9? — Jon <jon.forums@...>

As this may turn out to be a 3rd party issue rather than a bug, I'd like some feedback.

11 messages 2010/12/22

[#33833] Ruby 1.9.2 is going to be released — "Yuki Sonoda (Yugui)" <yugui@...>

-----BEGIN PGP SIGNED MESSAGE-----

15 messages 2010/12/23

[#33846] [Ruby 1.9-Feature#4197][Open] Improvement of the benchmark library — Benoit Daloze <redmine@...>

Feature #4197: Improvement of the benchmark library

15 messages 2010/12/23

[#33910] [Ruby 1.9-Feature#4211][Open] Converting the Ruby and C API documentation to YARD syntax — Loren Segal <redmine@...>

Feature #4211: Converting the Ruby and C API documentation to YARD syntax

10 messages 2010/12/26

[#33923] [Ruby 1.9-Bug#4214][Open] Fiddle::WINDOWS == false on Windows — Jon Forums <redmine@...>

Bug #4214: Fiddle::WINDOWS == false on Windows

15 messages 2010/12/27

[ruby-core:33687] Towards a standardized AST for Ruby code

From: Magnus Holm <judofyr@...>
Date: 2010-12-12 15:55:03 UTC
List: ruby-core #33687
Hey folks,

When it comes to working with Ruby files in Ruby (parsing, analyzing
etc), we definitely have a non-optimal solution right now. There's
plenty of parsers, but almost none work across implementations or are
compatible with each other:

* ParseTree. 1.8. Only parses 1.8 code (including internal). UnifiedRuby AST.
* RubyParser. Everywhere. Only parses 1.8 code. UnifiedRuby AST.
* Ripper. 1.9 / MacRuby. Only parses 1.9 code. Event based.
* Melbourne. C-extension. Only parses 1.8 code. Rubinius AST.
* JRuby's parser. JRuby. Parses both 1.8 and most 1.9 code. JRuby AST.
* RedParse. Everywhere. Parses both 1.8 and some 1.9 code. RedParse
AST. Not used as much as the other tools.

I'm proposing that we design and standardize a single AST which is
intended to be used by tools that works with Ruby syntax (Flog, Flay,
Roodi, Reek etc). Parsers can then produce this AST either directly
from the parser itself, or through a converter from the internal AST
to the standardized AST. Please be aware that this AST does not
mandate how the parsers/implementations should structure their
internal Ruby code; it's only a convention for how to work with Ruby
within Ruby in order to make it easier for all parts.

A long term goal is that every implementation should implement a
Ruby::Parser class which will parse the code with the internal parser,
and yet produce the same AST everywhere.

## Suggested plan

1. Design and standardize an AST together with a test suite (based on
current parsers' test suites)
2. Write converters for all the parsers above
3. Provide a gem with all of the converters which automatically
chooses the best internal parser on each implementation.
4. Make sure everyone targets this meta-parser instead of custom AST
provided by other parsers.
5. *If* this gets traction, each implementation can *then* provide
their own Ruby::Parser class and we can slowly deprecate the gem.

## How should we proceed with this?

First a few questions:

  Everyone, do you also see the value of this, or is it only me?
  Ruby core team, is there a way to make this an "official" AST?
  matz, what are your thoughts on a Ruby::Parser class?

Where should we continue discussing this AST? ruby-core? A new mailing
list? Somewhere else?

Also, if you know about someone who has either written a parser or a
tool that depends on a parser, could you please point them to this
discussion?

Thanks for your consideration,
Magnus Holm

In This Thread

Prev Next