From: Stefan Matthias Aust Date: 2001-05-27T18:10:05+09:00 Subject: [ruby-talk:15794] Re: Challenges of java interpreter Robert Feldt 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