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.