On Wed, 18 Apr 2001, Stefan Matthias Aust wrote:
> 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?

Because you can reuse that parser for parsing without executing, and then
Ruby basically becomes homoiconic. When this happens, a whole category of
programs become easier to write: compilers, editors, interpreters, ...

Also you can reuse that parser to put it in a third implementation or even
replace the one of the first implementation. If the parser is written in
Java then it becomes dependent on Java just like the current one is
dependent on C and Yacc.

> 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?

A parser should not generate anything; a parser generator has got to
generate a parser which is written in a language, and that language can be
Ruby just like the generator itself can be written in Ruby. But that
doesn't mean there should absolutely be a parser generator ("grammar
compiler") because it could as well be a "grammar interpreter" instead, or
something else, as long as it does the job.

> I already raised that question:  Is Ruby creating some precompiled
> intermediate language which then can be interpretered on a ruby VM?

A tree of objects; those objects are of special internal classes. 

> >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.

It's also best to continue with a subset of Ruby, or a superset of a
subset of Ruby, simply because there are things that don't map well from C
to Java, or even become irrelevant. Let me add three other things to the
list: 

* Garbage Collection (in JVM, it is none of our business)

* ObjectSpace, Object#id (can be done but may be costly)

* Ruby interface to C procedures (replace by: Ruby interface to Java
classes using reflection, constructed very differently for maximum
comfort)

> 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.

Well, a large enough set of unit tests becomes by itself a kind of formal
specification, albeit in an "organic" way (in the sense of making the
spec "emerge" from the mesh of tests)

Contracts, however, would help for more thorough testing, as they can test
correctness of library calls *while* executing "real code", thus
harnessing real code for doing real testing. Also the contracts are pretty
much formal specifications in the more usual sense.

I think it's a good idea to write contracts for Ruby's builtin classes.
Those could be merged into Rubicon (which would then have two related
purposes), or into Ruby itself, or into MetaRuby.

matju