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

On Fri, Jan 28, 2011 at 12:50 PM, Charles Oliver Nutter
<[e-mail]> wrote:
> On Thu, Jan 27, 2011 at 7:54 PM, James M. Lawrence
> <[e-mail]> 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.

I was making the gentlemanly gesture of considering the best possible
argument for the opposing view. The best argument I see for converters
is optimization. I'm not aware of a need for it, though Magnus may
know. I expect that interest in converters will fall away once
RubyParser is finished.

>> 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 :)

Yes, not for the real world, but good enough for writing runnable
tests, if live ASTs are ever considered for official inclusion. (I
recently added functionality for live proc ASTs as well.)

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

I think a full-fledged RubyParser together with an optional flag that
enables .source is the best solution for live ASTs, if .source is
feasible enough for implementations.