From: Charles Oliver Nutter <headius@...>
Date: 2011-01-29T02:50:29+09:00
Subject: [ruby-core:34941] Re: Towards a standardized AST for Ruby code

On Thu, Jan 27, 2011 at 7:54 PM, James M. Lawrence
<quixoticsycophant@gmail.com> wrote:
> A converter does make sense as an optimization. If a Ruby
> implementation stores the internal AST of a method (presumably some
> internal AST data exists before it gets converted into bytecode), it
> would certainly be faster to translate a single method's AST than to
> re-parse the file whence it came with RubyParser. Also remember the
> load time for RubyParser is significant.

What's the use case that requires this optimization? I'm not opposed,
but it seems like most runtime uses of parse tree are one-shot
deals...and even with an optimized form you wouldn't want to construct
a full sexp tree in hot-path code.

> It seems clear that RubyParser should come first. When it is fairly
> complete, and when an implementation supports storing AST data, that
> implementation can provide an optimized RubyParser (a converter).

Or simply make RubyParser faster...

> Regarding live ASTs, can't this be prototyped with RubyParser?
...
> http://github.com/quix/live_ast

I like the trick of using the original file source, reparsed, to get
the live AST. But the method_added hook would obviously not fly in a
real-world situation. I recognize this is just a prototype too :)

Adding .source to a few Ruby constructs would probably not be hard (I
think...I'm not the parser guy), and would enable even more than just
runtime ASTs.

- Charlie