On Tue, 17 Apr 2001 06:45:49 +0900, Mathieu Bouchard
<matju / sympatico.ca> wrote:

>I think the most difficult part of writing a "Ruby for Java" interpreter
>is getting the parser right. Of course that parser should be written in
>Ruby itself.

Why do you think this would be advantageous?  I noticed there's
something like RACC which seems to be a Ruby version of yacc.  A
parser in Ruby would perhaps help to formalize the grammar and make is
easier to understand than a yacc file, but what shall a Ruby parser in
Ruby generate?

I already raised that question:  Is Ruby creating some precompiled
intermediate language which then can be interpretered on a ruby VM?
In this case, you could implement just this RVM in Java and then
bootstrap a complete Ruby system (simple application of T-diagrams,
compiler construction theories) but otherwise...?

>I also think a version 1.0 of that, probably shouldn't support Threads,
>Continuations, nor Resumable Exceptions, but that's about all.

Yes, it's probably the best idea to start with a subset of Ruby.  Then
this subset can be extended.  Even for the C-Ruby version, it might be
a good idea to define such a subset as it might help porting the C
code other other systems - for example small system which have
not/need not (native) threads.

I also agree with another poster, that it would be very important to
make sure, that C-Ruby and JRuby have the same semantics.  I don't
think there's a formal definition of Ruby's semantic but a large set
of unit tests would also be very helpful.


bye
--
Stefan Matthias Aust \/ Truth Until Paradox