Leopold Toetsch wrote:
A few things to note: "foo" is a PMC. It therefore is an object. It can have state (properties, attributes, etc). It can "know" how many arguments are involved in multiple dispatch.
The MMD information can't hang off the Sub PMCs. How do you find the correct "foo" Sub then?
... This leads to the assumption that we'll need an opcode
call_MMD "meth", n_invocants
Changing the external syntax for subroutine calls in P6 may be an option. Changing the syntax for function calls in Python is not an option. Therefore, if changing the syntax is required, it is likely that Python will not be able to call arbitrary subroutines involving MMD.
Python doesn't have the concept of MMD. You can't specify the number of invocants in Python source code. So yes, if nothing is known about the subroutine, it's unlikely that it can be called from Python. If the translator is aware of the fact that a Perl6 multi sub is called, the call syntax can be adapted - however it'll look like.
It would be ideal if callers did not have to know how such subroutines were defined, and could continue to emit "invokecc" sequences on Sub PMCs, and for this to be handled at runtime.
Well, I don't know how the Perl6 compiler will translate:
foo($a, $b, $c)
If there is more then one "foo" Sub PMC around, the call syntax still must have the number of invocants attached to it, so that MMD can happen.
It's quite clear for infix operations like "add". For arbitrary subroutines the compiler has to know it, as outlined above.
When expressed via an infix notation, I agree that it is not a problem. When expressed via the equivalent method call notation, (as Python allows), it becomes one.
Please note that the shown method call syntax was an internal representation of the functionality. But WRT Python:
i = 1 j = 2 print i.__add__(j)
can be translated directly to the method call of Parrot's infix "__add" method.
And despite that it's looking like a "fat" method call, Parrot executes this sequence, if the "__add" isn't overloaded:
if (cache->type == (Py->vtable->base_type << 16|Pz->vtable->base_type) Px = (cache->function)(Py, Pz);
which is 30% faster then the current mmd_dispatch based opcode.
That code will execute just as fast if placed inside the "invoke" logic of a "MMD PMC".
Where does this hypothetical MMD PMC come from? Where is it created? The opcode is just:
add Px, Py, Pz
Py or Pz can be plain PyInts or Integers. Where does that MMD PMC come from?
And no, it wouldn't have the same performance.
- Sam Ruby
leo
