Re: Ruby to Parrot compiler (where is Ruth?)

Charles Comstock wrote:

> 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.
>
Ripper uses parse.y to generate it parser, so it is possible.

> 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.
>
I'm not sure that I follow you here.

Do you mean how to handle the eval instruction? In parrot there's an 
opcode that registers a function as being a compiler. then another 
opcode is used to compile a string to bytecode.

If you mean how to call code written in c there's the NCI interface 
which so far has been used to create parrot bindings to PostgreSQL and SDL

> 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.
>
My understanding is that Matz isn't going to release Rite until it is at 
a stage where it is running reasonably. I'm not sure how we can push to 
get Rite working till then.

I like the idea of having a plugable back end to the Rite compiler so it 
would be possible to get it to target the Rite Vm, Parrot, .net or the JVM.

Still even if this project is supersceded by Rite, I think it would at 
least make a good prototype.

--
Mark Sparshatt