Thinking more about that it seems that we don't have much chance to keep the current scheme that the destination is passed in.
(This is probably out of order -- I've a lot of mail I'm backed up on unfortunately, but since it was CC'd directly to me I'll take it)
The note here is that Parrot's MMD function signature for binary ops doesn't match what Python needs. Parrot is:
void binary_mmd_op(pmc left, pmc right, pmc dest)
where Python is:
pmc dest = left.add(pmc right)
And, as you can see, the difference is more than just python creating a destination where we require one to be passed in -- it's a method call as well.
I fully expected this to be an issue. Perl 5 and perl 6 are going to have different conventions, (and I think there may well be at least two separate ones for perl 6, but I may be misrememebering) Ruby doesn't match, and neither do any of the other languages. I think there was some discussion back when this was first batted around, but there might not have been.
The short answer here is to cope: that is, when installing an MMD function, including one of the default MMD functions for a class, a language needs to generate the appropriate wrapper function if necessary to translate between what parrot provides and what the language itself wants.
Nothing much for it -- no matter what we choose it's going to be wrong for someone, so the sensible thing to do is choose the scheme that works best for the underlying model (which we have) and leave it to compilers and class libraries to translate to their own preferred form. I think we're likely to find that the scheme we have catches on reasonably well once we've hit release and start seeing widespread use.
--
Dan
--------------------------------------it's like this-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
