TSa (Thomas SandlaÃ?) wrote:

>  Let's assume that op is overloaded for two completely unrelated types
>  A and B, which are both defining their respective identity elements
>  but !(A.identval =:= B.identval). How should the &op multi method object
>  pick the correct one *without* looking at $value's type?

Your mistake is in thinking that the identity trait is on the operand type. It 
isn't; it's on the operator itself.


>  Or is the
>  intent to enforce a unique identity value for each operator like 0 for +
>  and 1 for *?

Almost. Remember that overloaded operators are also distinguishable by their 
operand types, so you can specify separate identity values for C<&infix:<+> (Num, 
Num)>  and C<&infix:<+>(Matrix, Matrix)>.


>  There's actually a second problem. Will the &op.does(identval) condition
>  be true or false if the &op multi contains some targets with and some
>  without an identval?

The op will have already been selected by the MMD mechanism before that question 
is asked.


>  Finally I don't understand how the knowledge about a pending assignment
>  eases the choice problem for the multi. Note that the choice of
>  assignment operator depends on the return value of the operator and
>  the type of which the lhs is undef.

The MMD mechanism sorts out which op is required, either by looking at the 
static type of the lhs variable, or by treating the undef as a coercion 
(Manhattan distance = 1)

Damian