Re: [Cardinal-dev] test, &c.

[Phil Tomson]

On Sat, 20 Apr 2002, Pat Eyler wrote:

>
> On a more parrot-like note, have you looked at miniperl at all?  They seem
> to have a well tested base to work from.  It might prove a fertile field
> for reading, stealing ideas, etc.
>
> It may also be worthwhile for use to start now on the whole lexing,
> parsing, AST bit.  Although parrot won't be ready for call_method for a
> while yet, we could still get to the point where we have a solid front end
> by the time parrot's ready for us.

I think we can build on RUTH (see the code at:
http://sourceforge.net/project/showfiles.php?group_id=26000
)

>From the README: (NOTE: mri means "Matz Ruby Interpreter", I believe)

Author: Robert Feldt, address@hidden

What is it?
-----------
Ruby extension giving classes and functions to access Ruby internals.
Currently includes:

 * ruth/mri, Ruby::Interpreter.parse
    Gives a tree representing the internal parse tree used to execute a
Ruby
program.
 * ruth/mri, Ruby::Interpreter.method_body
    Returns the tree for the body of a method.

And a painfully incomplete:

 * ruth/parser, Ruby.parse
    Parse Ruby source code into an abstract syntax tree. Currently uses
RubySchema from Mathieu Bouchard's MetaRuby project to represent the
AST's.
Its a cheato-RubyInRuby parser since it looks like one but actually uses
Matz's Ruby Interpreter's parser and then simply transforms the output.
Advantage of this is that it parses exactly the same programs as MRI
parses(since it uses the same parser). Disadvantage is that it relies on
C code,isn't customizable etc.


>
> A last bit to think about (inspired by miniperl and sRuby), what do you
> think we need for a minimal subset of ruby?

Good question.  I guess I want to take a look at RUTH to see what's there
and what's not.  I think the advantage here is that RUTH should parse the
same programs the the current RUby does since it uses Matz's lex/yacc.

I get the idea that Ruth is sort of a kludge, but I think it might be
useful for this situation.  From some email exchanges with Dan Sugalski it
seems that ultimately we should write our parser using Parrot's native
parser tools, but since they're not close to being done yet we should
consider that the interim solution (using RUTH?) will be temporary.

So I guess we need to do some evaluation to determine which Ruby-in-Ruby
parser is most advanced at this point.

>
> -pate
>
> ps. I can meet you on irc at irc.openprojects.net #ruby-lang (or
> #cardinal) if you'd like to talk rather than trade email.

I have to admit that I've never used IRC (where have I been for the last
several years? ;-)  How would you suggest I get started?  I'm on Linux,
any suggestions for an IRC client?

Phil