From: "Jörg W Mittag" <JoergWMittag+Usenet@...>
Date: 2009-05-21T05:35:02+09:00
Subject: Re: Superclass of eigenclass

Danny O cuiv wrote:
> There seems to be two forces contributing to this. Firstly, the 
> profusion of terms (many of which are clearly misnomers) is getting out 
> of hand, and is unhelpful to newcomers. Secondly, many people still 
> resort to referring to MRI runtime structures when discussing semantics 
> even though Ruby is now being implemented on the JVM, on the CLR, on the 
> Objective-C runtime and presumably elsewhere.

Yet more runtimes: the Parrot VM (Cardinal), a modified version of the
64-Bit Gemstone Smalltalk VM (MagLev), the Flash/ActionScript Tamarin
VM (Red Sun) and the SAP NetWeaver/ABAP VM (Blue Ruby). Plus
specialized Ruby VMs (Rubinius, tinyrb).

> There is now a clear need 
> to be able to discuss semantics at a sufficient level of abstraction, 
> i.e. purely in terms of what is revealed by the reflection API. If there 
> are any inconsistencies or anomalies revealed by the API, then this 
> should be addressed directly.

Let's not forget the current ISO standardization work for Ruby.
Anybody remember Open OfficeXML? It was standardized by
reverse-engineering MS Word, exactly the way that you describe (which
is basically the way RubySpec works: reverse-engineering MRI and
YARV). In the end, it was so incredibly hard to implement that even
Microsoft itself shipped a working implementation of ODF (i.e. the
native OpenOffice.Org XML format) *before* OOXML (i.e. the native MS
Office XML format). [In fact, OOXML is widely believed to be
un-implementable, because of logical contradictions in the spec.]

We *need* a specification of Ruby's semantics, independent of MRI
and/or YARV, both for the sake of all the other implementations and
ISO Ruby.

Unfortunately, there is really only one person that could write such a
spec.

Ideally, of course, that specification would be both formal and
abstract enough, so that we can automatically generate an interpreter
from it, or at least a testsuite. Or feed it to an automatic theorem
prover, and have it prove interesting properties like memory safety,
$SAFE-level safety, consistency etc.

And now, I'm going down to the stables to feed my unicorn :-)

> The central point that I think should be made here is that per-instance 
> behaviour has nothing to do with inheritance, per se. One obvious 
> language rule will be that per-instance behaviour should take precedence 
> over instance-common behaviour and one convenient way of implementing 
> that is to snap an eigenclass into the chain between the instance and 
> its class. But that implementation-specific runtime structure won't 
> serve as a definition of the semantics for implementations that work 
> differently. Take, for example, a "Ruby in the browser" (perhaps one 
> already exists?) that translates onto the JavaScript object model.

HotRuby was (is?) an implementation of not "Ruby in the browser" but
"YARV in the browser". It was basically a YARV bytecode interpreter
loop written in JavaScript (meaning it requires that the Ruby
sourcecode gets pre-compiled with the actual YARV compiler, the
bytecode dumped to disk and then delivered to the browser as a binary
blob).

YARI (Yet Another Ruby Interpreter) aka IoRuby was an implementation
of Ruby (1.6, I think����� it was before my time) on the Io runtime in
Io, which is a prototype-based OO language.

There has been talk about implementing Ruby on top of V8, which is an
ECMAScript engine.

There has been talk about implementing Ruby on top of NekoVM, which
has a unified class/prototype model.

None of these implementations actually have come even close to doing
anything even remotely useful and of course couldn't even dream of
running (let alone *passing*) RubySpec. But, there is at least *some*
interest in running Ruby on top of "prototype-ish" runtimes.

jwm