From: Eleanor McHugh <eleanor@...>
Date: 2010-10-06T22:56:10+09:00
Subject: Re: how can we make a ruby compiler

On 6 Oct 2010, at 13:11, Rick DeNatale wrote:
> Languages differ in much more important and subtle ways than their
> syntax and surface-level semantics.  Those differences lead to very
> different architectures/strategies or whatever you want to call it.
> 
> Converting an OO program written in, say Ruby, requires adaptation of
> not only the language syntax, but the underlying class library, if you
> are converting to C++, you need to figure out what to do about the
> usage in the Ruby program of base classes, you do probably have
> several choices of C++ libraries providing things like collection
> classes, all of which will mismatch the interfaces of their Ruby
> equivalents, probably in frightening ways.
> 
> Replace Smalltalk/Ruby message send semantics with C++ virtual
> function calls, and the constraints change. Move the burden of
> accounting for and reclaiming the memory used by objects from a GC to
> the programmer and things get complicated, and often the performance
> of the hand-written memory management (copy constructors, reference
> counts ...) starts making the performance 'win' of switching horses
> much less certain.
> 
> This is Greenspun's tenth rule of programming at work.
> http://philip.greenspun.com/research/

Funnily enough this is one of the inspirations behind my golightly[0] project: if every significant program I write will end up with an ad hoc implementation of Lisp (or more often than not Lisp and several other languages) then why not just use an abstract platform that allows me to plug together Lisp machines, Forth machines, Ruby machines etc. and have them all operate on the same underlying type space?

This is subtly different to the traditional virtual machine approach as by taking seriously the notion of language agnosticism you end up with less a single machine and more a set of components that can be plugged together to build an infinite variety of machines that are each better suited to the particular tasks they're used for than a general-purpose VM. I suspect it's probably similar to the software IC concept you mentioned over on Core recently, but with the added wrinkle that I'm interested in building in generalised type space transformations if I can get my head around them. These would effectively provide a means of JIT translation between different language type models, including assembler-level type expression where practical. I suspect a big chunk of the winter is likely to be spent researching current developments in compiler theory in hopes someone else has already solved this problem... and if they haven't perhaps it's time I went back to Uni and got my Doctorate :)


Ellie

[0] http://golightly.games-with-brains.net/

Eleanor McHugh
Games With Brains
http://feyeleanor.tel
----
raise ArgumentError unless @reality.responds_to? :reason