On 12/27/05, Nicolas Cannasse <[EMAIL PROTECTED]> wrote:
> >>Anyone having a good idea for a call/cc API in Neko ?
> >>
> >
> > Not really but with these additions Neko will go higher up on my list
> > of targets for a coming Ruby compiler.
> >
> > Thanks for the good work,
> >
> > Robert Feldt
>
> That would be pretty interesting.
> Could you say more about your project ?
>
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.
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?
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?
Thanks,
Robert Feldt
---
Neko : One VM to run them all
