HaloO, 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 as well. 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. Regards, TSa. --
