I think it would be really cool if you could do this on top of the free Squeak
VM.

Quoting Peter Suk <peter.kwangjun.suk / mac.com>:

> Hello everyone,
>
> I thought I'd talk about my new project here, since there is a good
> chance that someone might be interested in it.  I'm planning to put
> Ruby on top of Smalltalk VMs.  Ruby and Smalltalk are very similar
> under the covers, so Smalltalk VMs are a very good match for the
> language.  This will give Ruby a much faster execution environment
> (perhaps 30X), VMs which are capable of incremental garbage collection,
> generational garbage collection that is so fast your progra still works
> even with an infinite loop allocating new objects (I do this as a lark
> sometimes), a wonderful debugger which will let programmers modify
> methods on the fly & continue execution, a "workspace" window where you
> can execute arbitrary code, a visual "inspect", a powerful "Refactoring
> Browser," an industrial strength OODB (Gemstone) with objects and
> methods you can define in Ruby, and a readily accessible meta-level
> which will allow Rubyists to readily modify their own language.  (For
> example, you could then use Method wrappers to very quickly implement
> an Aspect-Oriented Ruby.)
>
> My strategy for doing this involves writing a Ruby parser (or, rather,
> translating the existing one in JRuby to Ruby) then writing a Smalltalk
> Parser object to request parsing of Ruby code into an AST from a Ruby
> program outside of Smalltalk.  We then reify the AST inside the image
> and use it to compile Ruby methods into bytecodes.  (Multiple syntaxes
> can coexist in one Smalltalk image.)  Once this is done, we can then
> compile the external Ruby parser and bring it into Smalltalk.
> Afterwards, we can use the Refactoring Browser Smalltalk parser plus a
> little runtime type inferencing to incrementally transform the image
> into pure Ruby.
>
> We can do all of this without changing the structure of Ruby files &
> Modules or requiring Rubyists to do Smalltalk style image oriented
> development.  And for those of you sharp enough to wonder: yes, we can
> handle Modules, Mixins, and fully qualified Method names without
> changing the Smalltalk VMs.  (At least those that have Namespaces.)
>
> If anyone is interested, please drop me a line.
>
> --Peter
>
> --
> There's neither heaven nor hell, save what we grant ourselves.
> There's neither fairness nor justice, save what we grant each other.
>
>
>


--
R. Mark Volkmann
Partner, Object Computing, Inc.