On Tue, May 17, 2005 at 07:26:54AM -0700, Larry Wall wrote: > It does seem that the signature that provides more information should > be "rewarded" for that somehow. Maybe it's most useful if non-invocant > args (or non-invocant-YET args, in this case) are just considered to > be at "Any" distance when matched against "real" invocants. But we > also have to consider that any violated hard constraint anywhere in > the signature can disqualify the entrant entirely.
So, if neither Num.does(Str) nor Str.does(Num), is passing a "string" into
multi sub foo (Num $x) { ... }
considered a violation on the hard constraint?
If yes, I'd like to know if something like this should be the case ([1]):
Num is a class, and
NumRole supplying a minimal definition of prefix:<+>
or it's like this instead ([3]):
Num is a role, and
has a minimal interface of:
infix:<+> infix:<*> abs sign
and one of: prefix:<-> infix:<->
etc.
I think the former is simpler ("always use coercion"), but the latter
makes it possible to define various other things that, although not
isomorphic with builtin numbers, can still use arithmetic operators.
Thanks,
/Autrijus/
pgpvJ0CD0eTFk.pgp
Description: PGP signature
