Sam Ruby <[EMAIL PROTECTED]> wrote:
> Ah! Now we are getting somewhere!
Yeah. That's the goal.
> So, why have I proceeded in this manner? Two reasons.
Fair enough, both.
>> So given that we have a set of language-neutral PMCs in core that do the
>> right thing, Python or Perl PMCs can inherit a lot of functionality from
>> core PMCs. Language-specific behavior is of course implemented in the
>> specific PMC.
> Agreed. One area that will require a bit more thought is error cases.
Yep. But let's just figure that out later. First the basics.
> I'll address your questions below, but for reference, here is the code
> that Pirate generates for "a=b+c":
> find_type $I0, 'PyObject'
> new $P0, $I0
> find_lex $P1, 'b'
> find_lex $P2, 'c'
> $P0 = $P1 + $P2
> store_lex -1, 'a', $P0
Good. Now Evil Leo (who can't program in Python ;) writes some piece of
code like this:
$ cat m.py
class M(type):
def __new__(meta, name, base, vars):
cls = type.__new__(meta, name, base, vars)
cls.__add__ = myadd
return cls
def myadd(self, r):
return 44 - r
I = M('Int', (int,), {})
i = I(5)
print i
print i + 2
$ python m.py
5
42
> What this means is that the __add__ method will not be directly used for
> either PyInt or PyString objects
Well, and that's not true, IMHO. See above. It has to be part of
Parrot's method dispatch. What if your translator just sees the last 3
lines of the code and M is in some lib? That implies that you either
can't translate to "$P0 = $P1 + $P2", or that you just translate or
alias "__add__" to Parrot's "__add" and let Parrot fiddle around to find
the correct method.
>> * the method is returning a new PMC. This doesn't follow the signature
>> of Parrot infix MMD operations.
> Here I do think you are misunderstanding. The __add__ method with
> precisely that signature and semantics is defined by the Python language
> specification. It is (somewhat rarely) used directly, and therefore
> must be supported exactly that way.
| __add__(...)
| x.__add__(y) <==> x+y
Parrot semantics are that the destination exists. But having a look at
above "myadd", we probably have to adjust the calling conventions for
overloaded infix operators, i.e. return the destination value. Or
provide both schemes ... dunno.
> In the general case, looking for "reserved" method names at "compile"
> time doesn't work.
"__add__" is reserved in Python and corresponds directly to "__add" in
Parrot. I don't think that doesn't work.
> ... As everything can be overridden, this dispatch must
> be done at runtime.
Exactly and that's what I want to achieve.
> I personally don't think that performance considerations should be out
> of bounds in these discussions
I've already shown that it's possible to go with fully dynamic dispatch
*and* 30% faster for MMD and 70% faster for overloaded operations. First
correct and complete, then speed considerations.
> - Sam Ruby
leo
