Jeff Clites <[EMAIL PROTECTED]> wrote: > On Nov 5, 2004, at 9:40 AM, Leopold Toetsch wrote:
> In Python, semantically you know that you'll end up doing a method call > (or, behaving as though you had), so it's very roundabout to do a > method call by using an op which you know will fall back to doing a > method call. Clearer just to do the method call. No. The binary operations in Python are opcodes, as well as in Parrot. And both provide the snytax to override the opcode doing a method call, that's it. > The only thing that's special is that there are certain built-in > classes, and some of them implement __pow__, but that's not really > anything special about __pow__. Yes. And these certain *builtin* classes have MMD functions for binary opcodes. > And even the ops we currently have are broken semantically. Consider "a > = b + c" in Python. This can't compile to add_p_p_p, because for that > op to work, you have to already have an existing object in the first P > register specified. But in Python, "a" is going to hold the result of > "b + c", which in general will be a new object and could be of any > type, and has nothing to do with what's already in "a". That's a totally different thing and we have to address that. I have already proposed that the sequence: null dest dest = l + r should produce a *new* dest PMC. That's quite simple. We just have to pass the address of the dest PMC pointer instead of the PMC to all such operations. Warnocked. > ... I think > we should create PMC-based ops only if one of the following criteria > are met: (a) there's no other reasonable way to provide some needed > functionality, So, this is already a perfect reason to have these opcodes with PMCs. a = b + c behaves differently, if b and c are plain (small) integers or overflowing integers or complex numbers and so on. You can't provide this functionality w/o PMCs. > JEff leo
