Proposal: Remove Show and Eq superclasses of Num
R.Paterson at city.ac.uk
Mon Sep 19 01:10:42 CEST 2011
Edward Kmett writes:
> The problem that comes in is that this at the next proposal someone will come along and just say the same thing.
Not quite the same thing. I'm saying that Num is broken (which isn't a novel claim).
> "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.
That's an argument for never refactoring, and indeed for never defining classes in the first place.
> 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.
It's true that vector spaces, modules, etc are more difficult, but we don't need to fix everything to get the benefits of a more sensible structure. As for the lawlessness of Float and Double, you could say the same of the Eq instance for those types, and several Monad instances. It's a pity, but it's peripheral.
> 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.
But it's the instances of Num that are broken, usually lying about abs/signum too, and need to be changed, not the uses.
More information about the Libraries