Given a multi sub declaration a la S13:
multi sub *infix:<-> (MyInt $left, int $right) {mysub($left, $right)}
multi sub *infix:<-> (int $left, MyInt $right) {myrsub($right, $left)}The first one would create a MMD function variant of
sub_p_p_i or Pleft."sub"(Iright, Pdest)
or Pdest = Pleft."sub"(Iright)ok so far. The "PMC type" for the natural int is currently just zero. But it could be less hackish, if we just reserve three distinct type numbers for the namespace of these natural types.
The second one is harder. We don't have an opcode
sub_p_i_p
directly. But with the method call syntax the assembler could generate, it would boild down to:
P_int_namespace."sub"(Pright, Pdest)
where the P_int_namespace is the placeholder class for the MMD lookup of the natural int. Sounds doable too.
But what about an arbitrary user multi sub, e.g.:
multi sub *foo (MyInt $a, MyInt $b, int $c) multi sub *foo (MyInt $a, int $b, MyInt $c)
The assembler can create a prototyped call to a MMD "foo" function:
set I0, 1 # prototyped set I1, 1 # 1 I arg set I2, 0 # 0 S set I3, 2 # 2 P args set I4, 0 # 0 N call_MMD_3 "foo" # ???
or a method call on the first arg. But whatever we do, the function signature at the PASM level is the same for the first "foo" and the second one. We have lost the order of arguments, which is essential to find the appropriate MMD function or method.
Comments?
leo
