[Cardinal-dev] There Is No Wheel

[David Robins]

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".

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.

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.

Dave
Isa. 40:31