> I had a student some time back who started on a Ruby to CIL compiler.
However, continuations is a real problem/pain on the CLR/CIL so
if/when Neko supports that I have plans on having someone look into
using Neko as a first target instead of the CLR/CIL.
Neko will support continuations, since it makes a lot of sense to have
such feature handled at the VM level. It's just a matter of time.
I have barely checked out the basics of Neko so far though. Do you
have any recommendations on how people should/could be mapping
dynamically typed OO langs to Neko? A naive Ruby-to-Neko mapping would
be to simply use Neko objects directly but that will not work when
instance methods on inherited classes change (since I imagine $new()
really does a copy of all the fields of the object). One alternative
would be to do the recursive traversal of classes up the class
hierarchy explicitly by linking "instance prototype" objects. But then
each method call would have to be done with something like:
rmcall = function(object, methodint, args) {
lm = $objget(object, methodint);
if $typeof(lm) == $tfunction {
return ($objcall(object, methodint, args));
} else {
if lm == null {
so = [EMAIL PROTECTED]
if so == null {
throw("Method missing exception");
} else {
return rmcall(so, methodint, args);
}
} else {
throw("Calling value field as a method exception!");
};
};
};
but then it is not clear to me what I would really gain by using the
builtin objects. Can you elaborate on your ideas about language
interoperability on this issue?
If your object needs some specific selection of fields such as what
you're proposing, it will of course not allow transparent two-ways
interoperability. For example, you should be able to use any object
coming from another Neko language with your "rmcall" implementation.
However other Neko languages will not be able to call "super methods" of
Neko/Ruby objects unless they go through the "rmcall" stub.
So yes the representation of objects and the method resolution
implementation is an important part for language interoperability.
I guess other alternatives would be to "roll out" the hierarchy by
having the "instance prototype" object for each Ruby class having the
correct neko function in each slot and instead updating all the
affected "instance prototype" objects when there is a method
changed/added. However, it is not clear what performance/mem
implications that solution will have. Is there any sharing between
(similar/copied/cloned) neko objects?
Right now there is no sharing. When you $new(o) you allocate a new
object with a table which is a copy of the "o" table.
Here's a proposal similar to yours, but with method-sharing : the object
store "instance fields" and the prototype store "class fields".
proto = { f => function() { return this.msg; } };
inst = { msg => "hello", __proto__ => proto };
// call method
protocall = function(inst,proto,method,args) {
var m = $objget(proto,method);
if( m == null ) {
if( proto.__super__ == null )
$throw("no method");
return protocall(inst,proto.__super__,method,args);
} else
return $objcall(inst,m,args);
}
if( inst.f != null )
inst.f() // overriden method
else
protocall(inst,inst.__proto__,$hash("f"),$array());
This allow sharing, instance-specific overriding (since instance
fields have priority on prototype fields) and chaining. However it does
not allow transparent interoperability.
One possibility I see to achieve transparent interoperability would be
to be able to specify a "resolve" method when the field is not found :
protoloop = function(proto,field) {
var f = $objget(proto,field);
if( f != null )
return f;
proto = proto.__super__;
if( proto == null )
return null;
return protoloop(proto,field);
}
protoselect = function(field) {
return protoloop(this.__proto__,field)
}
inst = {
msg => "hello",
__proto__ => proto,
__resolve__ => protoselect
};
You'll notice that __resolve__ returns "null" when the field is not
found. In next version of Neko, there is more runtime exceptions so for
example a call on a value which is not a method with the correct number
of arguments will raise an exception.
__resolve__ looks like a good addition to the language, and it's nice to
be able to have this supported by the VM. If this solution is satisfying
for you I'll add it soon on NekoCVS.
Nicolas
---
Neko : One VM to run them all
