Charles Nutter wrote:
> On Wed, Aug 5, 2009 at 9:56 AM, Brian Candler<b.candler / pobox.com> 
> wrote:
>> I think that's the point :-) You *have* to pass it a String source for
>> it to parse. You can't take an object which Ruby has already parsed and
>> installed, such as method(:foo) in this case, and get the sexp from the
>> object.
> 
> Yeah, what's wrong with that?
> 
> Ignoring for the moment that different impls (and even different revs
> of MRI) have (often wildly) different AST structures...
> 
> The problem with expecting you can get an AST at runtime is that it
> means impls have to hold on to the AST for you. Guess what one of the
> largest startup memory costs is in MRI and JRuby...that's right, it's
> the AST from loading all that code into a big in-memory data
> structure. Ruby 1.9 doesn't have the AST available anymore for a good
> reason: it doesn't need it. JRuby won't need it soon either once our
> new compiler lands, and already doesn't have it available when you
> precompile code. So I guess it's a question of which is
> better...getting rid of that memory use or having the AST around all
> the time.
> 
> And again, that ignores that the AST is ever-changing and usually very
> different across impls.
> 
> - Charlie

I see the AST representation spitted by ParseTree as some sort of lisp 
like meta programming language in its own right (I've never used lisp 
but I am increasingly interested in it). I really don't care if it 
corresponds to Ruby internal representation as long as I can use it to 
generate Ruby code (or not Ruby code) and it provides a level of 
introspection not available without access to it.

I think I once saw a discussion between Ola Bini, Mentalguy and others 
about the need to have a common sexp representation across diferent 
implementations, some sort or Risp.

I think there is a gap in 1.9.x that RubyParser fills partialy as it 
only works with static code.

Thanks

Macario

-- 
Posted via http://www.ruby-forum.com/.