A ruling: The caller might not know that it's calling a multimethod at all at compile time, much less how many invocants it has.
This seems to invalidate calling conventions aka pdd03, *if* multi subs with native types are allowed. The register setup of calling these two multisubs is identical:
multi sub infix:<+>(int $l, Int $r) {...}
multi sub infix:<+>(Int $l, int $r) {...}There is no way to detect the ordering of call arguments (I5, P5).
A PMC that hides the fact that we're doing a multimethod seems like the best way to allow multiple language semantics. If we were OO designers, I doubt we would have thought of any other way.
Yes, basically. The question is which PMC. On the surface of a function call there is (in Python assembly terms):
LOAD_NAME "foo" CALL_FUNCTION
where the LOAD_NAME searches (lexicals, globals, builtins) for the name "foo". The question is, if Perl6 (or Parrot) can create a multi sub PMC with the "short name" (S12) "foo", or if only the "long name"s exist. The problem I see is namespace pollution, as it is totally valid that a locally defined subroutine "foo" hides outer multi subs of that name.
So, where does that OOish dispatcher PMC jump in?
Luke
leo
