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

Robert Feldt <[e-mail]> wrote:

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

Interesting...

>One thing that will be difficult if you want to go all the way is how to
>handle the C API.

Yes.  Currently, it exhibits a lot of the internals of the Ruby
interpreter.  IMHO this problem has a low priority.  I'm thinking
about a Java based Ruby and this wouldn't have a C API 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"

This would have been my argument:  If you look at Squeak's VM code, it
only barely resembles normal Smalltalk code.  Slang, as it is called
BTW, is really, as you say, C with Smalltalk syntax.  But it helps you
to get the job done and frankly, it wouldn't be difficult to make it
look more like Smalltalk, making it a little bit more powerful.  It's
just, nobody wants to work on that.  The initial translator was hacked
together in a few days and is now stable for a couple of years.

The most important reason (which is haven't mentioned in your paper)
for Slang is not that it looks like Smalltalk but that you can use the
Smalltalk development environment and test the VM inside that
environment.  You can simulate a VM in Smalltalk, single step through
any function, even run a simulated VM in a simulated VM (if you're
really patient :-).  Once you felt the power of a interactive, dynamic
IDE you know what this means.  This feature - Dan Ingalls, the
inventor of that VM, once said - made it possible to create the
original Squeak system in less than 3 months.

>Scheme-48 is a real good example).

Does Scheme-48 also use a VM?  Or is the PreScheme, you mention in
your paper, just used to create a Scheme 2 EXE compiler?  In the
latter case, a better approach would be to use a full featured Scheme
system and bootstrap itself.

>* Making Ruby internals more visible to more people.

I'm not sure whether this is really an advantage.  It's great if you
have access to a correct specification (as the code of course is) but
now the danger is that you relay on implementation features that could
change.  It's difficult to separate implementation details from
concepts that way.

>* Experimental testbed. 

This is really nice.  For Squeak, for example I once hacked the VM to
support multiple inheritance or true delegation - it never took more
than a few hours and was really fun :-)

>* 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)

A higher abstraction of the code often helps to implement better/more
sophisticated algorithms.  A modern GC like a generation scavenger
which would replace the current simple GC would probably give a speed
up which is more difficult to achieve in the current C implementation,
because it would be much more difficult to implement such a GC in C.

>[...] then why shouldn't it be good for coding compilers/interpreters 
>in general and Ruby ditto in particular?". 

Well, I think it would definitely be worth a try.  I still think the
probably best language to write compilers in is LISP/Scheme (perhaps
Dylan, I unfortunately never used that language) because one can make
use of most of either features for the own runtime system, but Lisp
and Smalltalk are somewhat exotic and people would probably prefer to
code in Ruby or C.  And Ruby has fortunately most of the features of
Smalltalk (and some of Lisp) to be good enough :-)


bye
-- 
Stefan Matthias Aust \/ Truth Until Paradox