Sebastian Fischer writes:
> Then Eq and Show must be superclasses of Num forever, which is the
> wart Ian wants to address. I think that these superclasses should be
> removed *and* the classes should be restructured along the lines of
> yap. I don't care in which order, so +1 from me.

If we had a Ring class, the superclasses of Num would be of much less
consequence.

The problem that comes in is that this at the next proposal someone will come along and just say the same thing.

"Now you have rings, but we really need semirings", so we can make a Bool instance that folks understand rather than the ugly boolean ring.

"Now you have semirings, but we really need right seminearrings" to model recognizing parsers.

Moreover, to properly factor out abs and signum you need MPTCs and, regardless, any instance of Ring for Float and Double is lying to you, due to the fact that associativity just flat out doesn't hold, so I would have reservations about introducing it as a superclass for Num.

At least in its current lawless state I don't feel guilty making instances for IEEE floats.

I favor this proposal because it is simple, has easily understood consequences, and doesn't require people who implement Num to do anything different, merely requires a few extra annotations in places where people were using Num but also wanted to be able to show or compare, while letting far more Num instances be defined without lying.

-Edward