Paul Brannan wrote:
> On Wed, Nov 12, 2008 at 04:28:32AM +0900, Charles Oliver Nutter wrote:
>> The problem with presenting parse trees are manifold:
>>
>> * The parse tree needs to be standardized or frozen
> 
> I disagree.  The parse tree can be presented to the user as an
> implementation- and version-specific interface.  There need not be any
> guarantee that the tree or the interface to the tree be stable across
> versions.

Doesn't matter if there's a guarantee. People will write to the MRI or 
1.9 tree and never bother with others. I'm not sure I see the value of 
adding such a core API that's not ever going to be compatible with other 
impls, especially when a targeted approach would probably work fine for 
most cases.

Exposing the raw parse tree is a cop-out, and doomed not only to 
eventually fail (or require constant maintenance and version-specific 
patching) across impls but across versions of the same impl.

>> * The parse tree needs to be retrievable at runtime (meaning you have to  
>> keep an AST or something similar even when you're not using it...huge  
>> memory waste)
> 
> This is a problem.  1.9 used to keep the AST around but doesn't anymore,
> presumably for this reason.

JRuby has it sometimes and doesn't have it other times, depending on 
compilation settings. I don't want to keep it around if I don't have to, 
since it represents a substantial memory hit.

- Charlie