TSa wrote:
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.
They can be:
$A > $B if $A.x > $B.x | $A.y > $B.y;
$A < $B if $A.x < $B.x | $A.y < $B.y;
This also allows you to unambiguously order any arbitrary set of
complex numbers.
Pipe dream: it would be nice if something similar to the above
(faulty) code counted as valid Perl 6 logic programming.
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.
The square root function doesn't cause any problem, even if it dies
when given a negative Num. What's important as far as type-checking
is concerned is that it would be defined for both real and complex
numbers.
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.
As I've pointed out above, it's possible to define Complex such that
it does the full set of comparison operators; I'm pretty sure that
there's nothing that Num can do that Complex can't do as well or
better.
But for the sake of argument, let's say that comparison operators
weren't possible for complex numbers. For the purpose of type
checking, saying that role Complex does role Num except for the
comparison operators would mean that saying that "Complex.does(Num)"
returns false. Mind you, it could be a detailed "false" value - say,
one that provides a list of every method that Num requires that
Complex doesn't implement - but it would still fail the type-checking
test.
IMHO, it would be nice if there was some way for perl 6 to let a
programmer define a subset of an existing role's interface as a new
role (a reversal of the usual process, akin to "deriving" a
superclass from a subclass) for those situations where the role
designer didn't have the foresight to realize that a particular subset
of the role might be useful on its own, and the programmer isn't in a
position to hack the original designer's code. As I envision it, this
_would_ modify the original role - slightly - so that it now 'does'
the new subset, thus allowing type-checking that looks for the new
role to accept anything that 'does' the original role.
Other than expanding the range of types that the original role will
match, this should have absolutely no impact on the original role's
behavior. In the above example, this sort of thing would let you
create a subset of Num that doesn't include the comparison operators
(say, UnorderedNum), which Complex could then compose.
But we're probably best off leaving this sort of thing for Perl
6.2831853 or later (see Apocalypse 1).
--
Jonathan "Dataweaver" Lang
