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