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).
>=20
> 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 !=3D defining the =
internals. It is very easy to manipulate the internal definition into an =
external definition.