Larry Wall wrote:
For various practical reasons I don't think we can treat Int as a
subset of Num, especially if Num is representing any of several
approximating types that may or may not have the "headroom" for
arbitrary integer math, or that lose low bits in the processing of
gaining high bits.
But we can have Int a subtype of Num? That would be very
practical for dispatch which uses the partial order of the
types. In particular mixed mode dispatches like 3.14 + 2
should be dispatchable to &infix:<+>:(Num,Num-->Num). And
of course there can be specializations for pure Int
&infix:<+>:(Int,Int-->Int). And for optimization purposes
there will be targets like &infix:<+>:(int32,int32-->int32^int64).
In other words there will be subtype relations between the
lowercase types like int32 <: num64. BTW, do we have something
like num80, num96 and num128 to support e.g. int64 <: num80?
If we do arbitrary integer math we might as well need to
do arbitrary floating math. The combinations need to be
picked such that the Int types are fully embedded in the
floats. E.g. 32 bit ints are embedded into 64 bit floats.
So whenever the Int implementation switches to a bigger
representation the corresponding Num has to make a step
In the abstract we could represent Nums as an integer
plus a remainder in the range 0..^1. Integers would then
be a proper subset with the constraint that the remainder
is zero. For full rational number support the remainder
must be capabable of repetitions such that 0.333... represents
1/3 with full accuracy and results like 0.999... are normalized
to 1.0. For irrational numbers the remainder might have a
closure that produces more digits if requested.