Proposal: Remove Show and Eq superclasses of Num
twhitehead at gmail.com
Thu Oct 13 23:31:37 CEST 2011
On September 15, 2011 19:47:18 Paterson, Ross wrote:
> This will break client code, but will not fix other defects of Num,
> namely the inclusion of abs/signum, and tying (*) to (+). I think the
> right approach is to refactor the numeric classes along algebraic lines:
> Leave Num with its broken interface for backward compatibility (for
> clients), but provide a clean Ring superclass for new code.
I was looking through YAP a bit and was not certain about what was there only
for compatibility as apposed to because it was also still good.
Am I correct in understanding, if you were starting from scratch:
- Num, Fractional, Real, and Integral would get axed, and
- EuclidianDomain, Ring, and Field would form the base.
Would you then leave RealFrac, Floating, and RealFloat with superclasses
- RealFrac: Field
- Floating: Field
- RealFloat: RealFrac, Floating
or overhaul them too somehow? The choice of functions for Floating has always
seemed somewhat arbitrary. Not so much that I'm saying the the choice of
basic transcendentals was bad, but the fact a choice had to be made seems bad.
Perhaps there should be classes for groups of related functions instead?
More information about the Libraries