From: Robert Feldt Date: 2003-07-31T06:12:34+09:00 Subject: Re: Ruby in Ruby Mauricio Fern�ndez skrev den Wed, 30 Jul 2003 23:42:51 +0900: >> > It also would give you a >> > pluggable library you could use in, say, a syntax-highlighting IDE or >> > refactoring browser, since you can't properly highlight syntax or >> > refactor if you can't parse the code. >> >> Yep, that's an advantage! > > Another possibility (currently explored by the Pypy project and based on > Squeak's VM) is translating the code, written in some sort of restricted > Ruby (perhaps Robert Feldt's SRuby) to C, and them compiling. You could > get some serious optimization opportunities if some type inference or > profiling is done before. > Imho, there would be many advantages to a RubyInRuby approach. You can check my idea papers for RubyVM for a listing (http://www.ce.chalmers.se/~feldt/ruby/ideas/rubyvm/). In the long run I actually think you could get better or close to C performance from it since the flexibility and ease of experimentation it buys you makes more powerful analysis and optimizations possible. However, that means that there must be a critical mass of folks willing to spend time on it. Our RubyVM/SRuby thing never really got started. If I were to start something similar today I think I would aim for the Jalapeno/Java approach, ie. skipping all intermediate steps and go directly from Ruby to machine code. It sounds insane but it would be coolest and has the most opportunity for optimizations in the long run. It would also make Ruby stand out somewhat since Python is already doing a squeak-like PyPy. A plus with skipping intermediaries is that they never really quite do what you want which means you can't use all your knowledge to make things better/faster etc. Also you don't need to learn all the quirks of an intermediate tool (understanding gcc's optimization effects for example which motivated c--). The projects I would study the most for the back end stuff would be Ocaml (excellent backend that generates assembler and then invokes gas, resulting performance is top notch), C-- (excellent idea but have never really taken off), and IBM's Jalapeno. When you have the flexibility that a RubyInRuby implementation gives you you could also connect that to optimizarion techniques like genetic algoritms and programming and optimize the code based on real-world data. But that's more of bleeding edge programming language research than purely an implementation project. I guess I'm way too much of a dreamer for my own good... ;) Regards, Robert Feldt