cardinal-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Cardinal-dev] Ping?!


From: Phil Tomson
Subject: Re: [Cardinal-dev] Ping?!
Date: Wed, 13 Nov 2002 22:20:12 -0800 (PST)

On 13 Nov 2002, Erik [ISO-8859-1] B?gfors wrote:

> On Wed, 2002-11-13 at 11:24, Einar Karttunen wrote:
> > On 12.11 16:12, Erik B?gfors wrote:
> > > Should we get this thing started??  Could people please say if they are
> > > interested in helping and what they want to do?
> >
> > I could work on either on the compiler implementation, or implementing
> > Ruby standard library on top of parrot.
>
> Great!
>
> > I have some experience doing stuff like this, and have written few compilers
> > and VMs. However I don't currently have the time to start designing things.
> > I'd love to use a parser understanding EBNF as a basis instead of the
> > parsers currently available wich interact directly with bison/yacc.
> >
> > I think I could write a such parser before christmas in Ruby. This would
> > help other projects also. Of course the first goal is a stable API and
> > not performance.
> >
> > We can cheat a little bit in the compiler, as we don't have to do stuff
> > like register assigments/overflow ourselves. As there is a tool for
> > doing that from symbolic parrot assembler code.
>
> I assume you mean using imcc?
>
> It would be great to see a parser before christmas but there are many
> different parsers and what we really need is a compiler.  (of course,
> there might be reasons not to use any of the current parsers and write a
> new but be aware of the once that do exist)
>
> I think we should try to agree on a way forward together.
>
> So.  You and the other people that wants to work with the
> compiler/parser should really talk and decide which way to go.
>

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

Yes, it would ultimately be nice to have a Ruby parser written in Ruby and
that should be the longterm goal.  If we can agree on how the AST should
look (and I think Ruth actually uses RubySchema which was an AST
definition developed by the Ruby-in-Ruby project) then it should be
possible to eventually get rid of Ruth and replace it with a Ruby parser
written in Ruby.

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.

Phil





reply via email to

[Prev in Thread] Current Thread [Next in Thread]