Darren Duncan wrote:
For example, the extra space of putting them aside will let us expand them to make them more thorough, such as dealing well with exact vs inexact, fixed vs infinite length, fuzzy or interval based vs not, caring about sigfigs or not, real vs complex vs quaternon, etc.
I agree with the general idea that this is non core (from an implementatin perspective); but one thing struck me here (slightly off topic, but not too far): a quaternion cannot be a Num because anyone using a "Num" will assume that multiplication is commutative (for quaternions, $a*$b != $b*$a).
It would be good if the type system could catch this type of thing; e.g. as a trait on the infix:<*> operator that would prevent the composition of the Num role from the Quaternion role because of this operator behavioral mismatch. The fundamental types should offer very strong guarantees of their behavior: implementations can differ in their precision and accuracy; but not much more.
