On Dec 12, 2010, at 15:10 , Urabe Shyouhei wrote:

> (2010/12/13 1:54), Haase, Konstantin wrote:
>> Also, such a parser cannot be used to inspect a live system (accessing the AST for a method or closure, for instance) unless it would be possible to access the source code of those (as in JavaScript). Therefore it cannot be used for say partial evaluation in a live system (pypy does this for generating extremely fast code).
> 
> I doubt MRI people (namely Matz) allow you to access a live system AST.  They
> believe ASTs are not standard part of Ruby.  These days any small part of MRI
> tend to be regarded as a Ruby standard (like refinements) and that would bind
> core people not to change it.  Language designers tend to hesitate the
> situation they cannot touch their own language internals.  So, as far as this
> proposal is aiming to make a standard, to inspect a live system is fairly
> undesirable for them.

ParseTree had no (ok... few) problems converting from actual MRI AST to "Unified" AST (a cleaned up AST that had less implementation details in it). Providing a standard AST definition for consumers != defining the internals. It is very easy to manipulate the internal definition into an external definition.