From: Ryan Davis <ryand-ruby@...>
Date: 2004-12-27T02:19:20+09:00
Subject: Re: Revival of RubyInRuby?


On Dec 26, 2004, at 4:30 AM, Michael Neumann wrote:

> That's great news. Very similar to what I thought. But I don't see a 
> reason for implementing the parser in a subset of Ruby (except for 
> performance). Once you've bootstrapped the parser to bytecode with 
> real-Ruby, you can load it into the VM.

I wasn't planning on making a bytecode step. The system is architected 
in such a way that it is possible (and easy--eric has done a 
prototype), but it wasn't in the plans.

> How active is the project? Who else is working on it?

Taking a minor vacation this month, but it is Eric and me w/ some 
close-by projects that may merge in the future.

> Parser: I'm currently hacking a bit on my packrat project and try to 
> get a TPDL (Top Down Parsing Language) generator working. It's pretty 
> slow (~1000 lines per second), maybe if I implement memoizing it will 
> become faster. Nevertheless, it would be fast enough if you precompile 
> the whole libraries to .rbc, and use the parser only for "eval" at 
> runtime. I don't think that this would be a big performance penalty.

You might want to check out coco/r(uby) (on rubyforge as cocor). It is 
the coco/r RDP framework ported to ruby (and generating pure ruby). I 
haven't benchmarked it at all, but I suspect it does pretty well.

> Garbage Collector?
> Any concrete plans, which strategy to use? Using a non conservating GC 
> would break with existing C extensions. But if they'd be rewritten in 
> Ruby2C language, the generator could automatically generate code for a 
> conservating GC or a non conservating... I'm for a non-conservative 
> due to the reasons I said in the last email.

non-conservative won't necessarily break C extensions as far as I 
understand. It'll just have to jump through some extra hoops.

> My idea for the Ruby2C translator is very similar, but more C oriented 
> than yours (it's not only for extensions). Example:

ruby2c isn't for extensions at all. If you could tell me what gave you 
that impression (like a slide or something, I'll fix it).

> The types of the instance variables are automatically infered. Types 
> or local, argument and return values have to be specified via 
> def_type. Special methods like deref(value) would map to *(value) in 
> the C output.  Constants map to MACROS, so they are simply replaced 
> with their name in the C output:

We do type inference already, without a map.

> And of course method calls map to function calls in C, with the 
> difference that, if the method is defined in the class, then the self 
> argument is passed, otherwise a real function call (as for printf) is 
> performed.

Here is where we have maps, but only for mapping into the standard C 
library.