Proposal: Remove Show and Eq superclasses of Num

[Jon Fairbairn]

Yitzchak Gale <gale at sefer.org> writes:

> +1 on removing the Show constraint.
> I abstain on the Eq constraint - either way is fine with me.
>
> Jon Fairbairn wrote:
>> But pattern matching for Double or Float is a Bad Thing, so
>> wouldn’t the solution to this be to put the EQ constraint
>> somewhere else, such as Integral where it would be less
>> improper?
>
> The Badness comes from the Eq instance itself. Once that
> instance exists, using it for pattern matching isn't any worse
> than equating with a Num literal in an expression. If we are
> going to have an Eq constraint at all, it might as well be on
> Num.

I don’t see the logic of that. The problem is that having an Eq
constraint on Num forces people to give Eq instances for types
that do not naturally have them, such as Real types. Certainly
there’s little difference between using (==) and pattern
matching, but the issue was that removing the Eq constraint
from Num would make programmes that test equality (either way)
on integers require the programmer to add “Eq t => …” somewhere
in a programme that previously didn’t require it.

Moving the Eq constraint to Integral would mean that programmers
declaring instances would only be required to add Eq when making
something an instance of Integral, a class that one would
naturally expect to have equality, while programmers simply
using Integer or Int &c would need to make no change (and
programmers using pattern matching on Double would get the error
they deserve).

-- 
Jón Fairbairn                                 Jon.Fairbairn at cl.cam.ac.uk