From: Avi Bryant <avi@...4.com>
Date: 2001-10-03T11:15:32+09:00
Subject: [ruby-talk:21972] Re: Let's work on Windows support

On Wed, 3 Oct 2001, Nat Pryce wrote:

> The CLR component of .NET is no more than a common virtual machine for
> different languages -- think of it as a high-level, architecture neutral
> Windows API.  If a Ruby interpreter can be written for the JVM it can be
> written for the CLR.  It won't affect the language definition, or give
> Microsoft control over the evolution of the language, any more than writing
> a Ruby interpreter that calls Win32 API functions would do.  The drawback to
> implementing Ruby on the CLR would be that the implementation would not
> share a common code base with the pure C implementation, and so it would be
> hard for it to keep track of Ruby's evolution.  Advatages would be a
> simpler, faster implementation (as far as I understand it) because the CLR
> implements garbage collection, threads, polymorphic dispatch, and JIT
> compilation for faster code.

The question with such things is whether the CLR is flexible enough to
support Ruby's language features.  I have a suspicion it won't be; I know,
for example, that the Hotdog scheme compiler was unable to support
continuations properly on .NET.  If Ruby's object model is sufficiently
different from that assumed by the CLR, you lose almost all the benefits
(ie, transparent interoperability with other languages).

Another interesting possibility, if it ever solidifies out of vaporware,
would be the AOS from smallscript.net - David Simmons is implementing what
looks like a very sophisticated runtime on top of both .NET and linux; I
would be more confident that it could support Ruby than the bare CLR.
I thought I saw his email in the list of RubyConf attendees, so perhaps we
can go into more detail there... ;-)