[ruby-talk:15778] Re: Challenges of java interpreter

On Sun, 27 May 2001, Stefan Matthias Aust wrote:

> >To create a java interpreter for ruby, ruby would ideally be coded in itself
> >(MetaRuby).  We should identify functionality which would be particularly
> >painful or inefficient to code this way, so we can discuss alternatives:
> 
> Well, this would be only useful IMHO if there's a way to compile the
> ruby code into another language - be C or Java or whatever.  Look at
> the Squeak Smalltalk project how to do it right.  The advantage here
> is, that you can debug the Squeak VM in Squeak itself.  This would
> then also be possible with Ruby.  However, Squeak isn't as fast as it
> could be if you'd code it directly in C/Assembler.  Dolphin Smalltalk,
> another Smalltalk interpreter which is written in optimized
> C++/assembler is much faster.
> 
> However, it would be nice, if most parts of the runtime library would
> be coded in Ruby.  It seems, nearly everything of String/Hash/etc. is
> coded directly in C, even if you could express most methods based on
> other methods.  This is of course done for speed, but now, it adds to
> the work needed to implement Ruby in a different language.
> 
The RubyVM project emanating from [ruby-talk:10238] is very related to
this discussion and you might want to check out some of the stuff on the
URL www.ce.chalmers.se/~feldt/ruby/ideas/rubyvm.

Especially the two documents

 www.ce.chalmers.se/~feldt/ruby/ideas/rubyvm/rubyvm.pdf

and

 www.ce.chalmers.se/~feldt/ruby/ideas/rubyvm/sruby.pdf

which describes later thinking on the porject than the 10238 message.

Things have stalled a bit because I'm on a part-time parental leave and
don't have much time left for Ruby-related work and the little time I have
goes into rockit (bound to be released soon as always ;-)). I hope I'll
get some more time in the coming months.

> >Could those of you more familiar with ruby add more to this list, especially
> >areas that you think would be most painful to express in java or metaruby.
> 
> I'm not that familiar with Ruby yet, but the area I see the most
> difficulties is the somewhat "feature"-driven handling of local
> variables and the eval code in general.  Otherwise, I don't expect
> problems to port the class library once you get the hidden meta level
> (how to represent class and method objects) right.
> 
One thing that will be difficult if you want to go all the way is how to
handle the C API. If you dont you will loose some or all extensions which
is definitely a bad thing. But if you take the compile-to-c approach
(which I think is the most sensible one) then, at least in theory, you can
supply some kind of Ruby-C-Api mapping/compatibility layer.

However, I think maybe the biggest win with having a pure-Ruby
implementation of Ruby itself (well almost...) is that people can go in
there and see how things are done. I think it will also be simpler and
cleaner. If not then why are we using Ruby anyway? Or are there good
arguments why Ruby would not be good for low- or system-level
programming? (After doing some research I don't think Squeak is a good
example anymore since its core is more "C-with-a-Smalltalk-syntax" than a
Smalltalk-subset but Scheme-48 is a real good example).

So some of the main reasons for doing MetaRuby/RubyInRuby/RubyVM IMHO is
(from the top of my head so I probably forgot some):

* Making Ruby internals more visible to more people.
* Documenting internals. (I wonder how this really works? Lets have a
look...) {Problem is it will probably be difficult to make it really work
the same everywhere...} But in this process more people will also
understand how things work beneath the surface => can't be a bad thing.
* Flexibility. I don't like this GC since I only have this little memory
or I need a GC with real-time garantuees... Subclass and implement your
own! Or: I don't need Regexp's, Bignum, File or X and need a small ruby
binary... Take them out! etc (IMHO, flexibility is also a prerequisite for
optimisations (on a high-level, philosophical level at least) since it
give room for variation and selection)
* Experimental testbed. Ruby should have this feature or Ruby should not
have this. Experiment and see what happens if you add/remove the feature
before doing a "real" C implementation...
* Fun. Its cool and begs to be done.

and the main drawback would be performance. (I almost dare not say this
but in the longest run I'm not sure this will really be so. As researchers
come up with new ways of compiling/interpreting/packing/executing programs
(or hardware affecting any of these processes) I think we can more easily
code these things up in Ruby and make use of and adapt to
them when executing our Ruby code than if we have to do a
not-as-easily-developed-and-changed C implementation. I
guess the main argument in much of this boils down to: "If Ruby is 
so good for programming the things we need in the real world (and I
really think it is; I don't see it as "simply" an OO scripting
language but as a general-purpose language (the silver bullit comes
flying by once more, eh... :-)) then why shouldn't it be good for coding
compilers/interpreters in general and Ruby ditto in particular?". However,
please do not interpret me as being on some absurd quest to replace Matz
Ruby interpreter or whatever. Basically I think RubyInRuby/RubyVM makes
sense (nice feeling in my stomach) and seems like a fun thing to do. What
happens then is a different and later story.)

Would be great to hear Matz (and Guy?) comment/elaborate on why he/they 
doesn't/dont fancy a meta approach? (Maybe you meant "...in replace of a C
approach" in which case I'm bound to agree)

Regards,

Robert