Re: [Cardinal-dev] There Is No Wheel

[Phil Tomson]

On Thu, 14 Nov 2002, David Robins wrote:

> On Wed, 13 Nov 2002, Phil Tomson wrote:
>
> > At this point I'm thinking that Ruth probably offers the best near-term
> > solution.  Since it essentially uses Matz's parse.y it's compliant.
> > We can get an AST out of it.  From the AST we can produce PIR which can be
> > fed into imcc (at least that's how I understand that it should be done).
>
> The announcement of the current version
> (http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-talk/33555)
> describes the parser as "painfully incomplete".

I believe that refers to the AST part.  There are still many node types to
be defined apparently.  But I think it will parse Ruby - it's just that
right now the AST wouldn't be as completely defined as we would like.

>
> Does _ANYONE_ (besides Matz in the ruby source) have a parser that can
> reliably take ruby code and return an AST?  I don't want to reinvent the
> wheel, but it's starting to look like there is no wheel.
>

>From what I can tell, Ruth and ripper are the most complete.

> I look a look at IMCC yesterday, looks like good stuff, I'm glad we don't
> have to do register spillage (had enough of that with the C compiler,
> especially with Intel's pittance of GP registers).
>
> > Here's a question for Dan: What about eval?  Say we're running on parrot
> > and someone wants to eval a string of Ruby code?  What happens?  I assume
> > it has to call whatever Ruby parser we have.
>
> Indeed.  (Although if people are doing silly things like eval'ing const data
> we can cheat and "pre-eval" it.)  We'll need to generate bytecode on the fly
> and run it in the current context, which reduces to the basic problem of
> parsing/running ruby code under parrot.

Mostly I would suspect it wouldnt' be const data that would be eval'ed.

Phil