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

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

> >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.
> 
Agreed, but if you want to go all the way... ;-)

> >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.
> 
Ok, I see. I still think that there is something to be gained by not
restraining the Ruby subset too much but being able to write as normal
code as possible when writing the core. You would still be able to use a
powerful IDE etc. Since there is currently none (?) for Ruby maybe this
point isn't a biggie yet...

> >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.
> 
No, it uses a VM written in some 2000 lines of PRe-Scheme code that is
translated to some 13000 (I'm not sure I remember correctly) lines of C.

> >* 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.
> 
Yes, maybe this is a real danger. I'd rather let the power loose and try
to correct any mistakes made but that's more of a personal philosophy...

> >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.
> 
Yes, this illustrates my point.

> >[...] 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 :-)
> 
Can you elaborate on what LISP/Scheme has that Ruby doesn't that is good
when writing compilers/interpreters/VM's?

Regards and thanks for grreat ideas/opinions,

Robert