From: Robert Feldt Date: 2001-05-27T07:29:45+09:00 Subject: [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