From: Charles Oliver Nutter <charles.nutter@...>
Date: 2009-02-28T05:22:32+09:00
Subject: Re: Nexus Programming Language

David Masover wrote:
> Merb uses ParseTree for something called ActionArgs feature which, as I 
> understand it, actually relies on the name of function parameters. For 
> example, if you have an action which takes an argument called 'foo', and 
> that URL is hit with a querystring like ?foo=bar, it will pass that 
> value ('bar', in that case) as that argument.
> 
> This actually seems to no longer need ParseTree -- that's used on MRI -- 
> but it also seems to have very different code for each of the three VMs 
> supported.

Well, in JRuby this is taking advantage of us being the most reflectable 
Ruby implementation. Basically it's a bit of Ruby code that accesses 
JRuby internals directly to get at the method args. That approach works 
reasonably well for small cases, but we'd probably want to expose our 
AST to Ruby in a more direct way that could then be massaged into sexps. 
JParseTree tried to do this, but without any JRuby runtime/API 
help...I'm willing to provide that help, if someone wanted to give it 
another go.

However there's another complication with exposing the AST: sometimes we 
don't have one. For example, if a script is precompiled to JVM bytecode, 
there's no AST to present. And we would like to get to a point where JIT 
compiling a method at runtime makes its associated AST eligible for GC, 
since a substantial portion of memory in a typical Ruby app is taken up 
by the AST itself. What do we do in those cases?

> Ideally, the goal wouldn't be to emulate MRI's warts, but to expose 
> something generic enough to be common, but practical. I would hope it 
> would do a good job of exposing the original structure of the source 
> code, even if that is completely annihilated by optimizations in the 
> version actually executed.

Sure, I'm game for that. And with a little more revising, I think the 
"unified parse tree" in later PT releases is pretty close. If we wanted 
to do this right, we'd get the implementers together to agree what a 
standard sexp-based representation of Ruby code should look like, 
avoiding impl-specific warts and conveying exactly the information needed.

> In fact, I think the closest we have to "something like ParseTree" which 
> "helps support alternate implementations" might be Rubinius. 
> Unfortunately, I don't seem to see any of the other alternate 
> implementations moving in that direction.

Rubinius is actually eliminating the intermediate sexps now because 
going from parse to sexp to AST to compilation is just too slow. But 
they're still basically using MRI's C parser, so PT is probably still 
supportable in some capacity.

- Charlie