HaloO,
Jonathan Lang wrote:
If at all possible, I would expect Complex to compose Num, thus
letting a Complex be used anywhere that a Num is requested.
This will not work. The Num type is ordered the Complex type isn't.
The operators <, <=, > and >= are not available in Complex. Though
I can imagine Num as a subtype of Complex. But I'm not sure if there
are cases where this breaks down as well---the square root function
comes to mind. With the root of a negative Num returning NaN or
Undef of Num which are technically Nums we could save the subtyping
relation.
In the end I think the two types Num and Complex both do a number
of common roles but don't have the same set of roles they do. E.g.
Comparable is available only for Nums. Basic arithmetic operations
like +,-,* and / are shared. The bad thing is that it will be
inconvenient to use. E.g. just using Num as parameter type in a sub
that does not use comparison should allow calling with a Complex even
though the nominal type is incompatible. IOW, the type inferencer
should determine a much more differentiated type than simple Num for
the parameter. How this type is then advertised I don't know.
Regards, TSa.
--
