From: Charles Comstock <cc1@...>
Date: 2004-02-22T05:14:52+09:00
Subject: Re: Ruby to Parrot compiler (where is Ruth?)

Robert Feldt wrote:
> Mark wrote:
> 
>> Thanks, that link works. Though the file linked there is misnamed. It 
>> has the extension .tar.gz even though it's just a tar file.
>>
>> It seems that the choice for a front end is between Ripper and Ruth. 
>> Both'll need a bit of development before they can be used, and neither 
>> is documented.
>>
>> Personally I think Ruth is the better choice since it has fewer 
>> dependencies (Ripper needs bison and gperf) and it's interface seems 
>> to be simpler.
>>
>> Though it has the problem that when parsing a method definition using 
>> the standard parse method there's no way to find out what parameters 
>> the methods takes. However I think there might be lower level methods 
>> which can be used in this case.
>>
>>
>> ISTM the best bet would be to design the compiler so that the parser 
>> can be swapped easily. Looking at the archives for Cardinal I noticed 
>> there was talk of Rite having a seperate parser component. Being able 
>> to use that as a parser would be very useful.
>>
>>
>> I'm going to set up a project on Rubyforge in order to work on this.
>>
> On Ruby parsers I might also mention that the new version of Rockit 
> (that I've used internally in my research for some time) has a Ruby 
> parser. Rockit's new model is to automatically generate an AST-builder 
> class that builds an AST for you when parsing. If you want your own 
> callbacks without building the AST you can just subclass or write your 
> own builder class and initialize the parser class with that. It seems to 
> be a fairly good compromise between the different parsing "styles". I 
> have planned to release it for long but it has some non-open code that I 
> need to get rid of. I've sat dates before so I won't do that again 
> though so you might be better off with something else for now... ;)
> 
> Anyway, the idea is that both Ruth and Rockit's Ruby parser should 
> generate the same AST so that they can be tested against each other for 
> conformance.
> 
> /Robert
> 
> 
> 
> 
> 

How hard is it to just piggyback on top of parse.y from the ruby source? 
  Or does a lot of evaluation take place still in that file.  You could 
however just change what each of the actions to do to match your 
backend.  Unless you want the byte-code compiler to be entirely self 
hosting of course.  But if Rocket depends on bison anyhow you don't get 
anyway.

I guess the problem I am seeing with the parrot compiler is all the code 
that is C-calls into the interpreter.  How do you plan on keeping that 
ability, while adding the benefit of parrot?  I'm curious how the 
interop works with parrot.

Another point is that while I think this is a great idea, maybe we 
should push to get a Rite compiler working, but make it have some sort 
of pluggable middle/backend so that we can drop out bytecode or just 
interpret in C.  It just seems awkward to rush ahead and get a bytecode 
compiler for a bytecode platform that hasn't completely standardized, 
just before the language your compiling is going through a standards 
change that may break code.

Just my 2 cents,
Charles Comstock