Proposal: Make Eq type class single method

[Tom Ellis]

On Mon, Oct 25, 2021 at 11:04:50AM +0200, Joachim Breitner wrote:
> current status of this train of thought:
> 
> * Most people here were sympathetic about the removal of (/=) from Eq.
> 
> * It would break a bit of code, but with an easy and backward-
>   compatible fix.
> 
> * The GHC implementation is straight forward:
>   https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6793
> 
> * There is _no_ measurable performance benefit in real-world-code.
>   A few of GHC’s perf regression tests benefit slightly:
> 
>     T12234(optasm) ghc/alloc    57633544.0    55409592.0  -3.9% GOOD
>     T18304(normal) ghc/alloc    87566616.0    83503296.0  -4.6% GOOD
>       T783(normal) ghc/alloc   389240752.0   377482584.0  -3.0% GOOD
>      T1969(normal) ghc/max    19869024.0    19071720.0  -4.0% 
>     T11545(normal) ghc/max    35580832.0    33828936.0  -4.9% 
> 
> * There is a problem with rules matching on class ops of single method 
>   classes: https://gitlab.haskell.org/ghc/ghc/-/issues/20535
>   I consider this a GHC bug that needs to be fixed anyways, so let’s
>   assume for now it will be fixed one way or another before Eq becomes
>   a single method class.

I'm a bit lost.  If there's no performance benefit then what is the
benefit?  Your original email alluded to

> it’s awkward to explain “this mechanism is useful if you can have an
> optimized implementation, but, eh, here it isn’t really possible”.

Is that really the whole motivation?  It's awkward?  If so then
breaking every library maintainer who has ever added an explicit
definition of (/=) seems like far too high a price to pay.  Haskell
library maintainers are already crying out about the burden of simply
keeping up with breaking changes (I see it a lot on Twitter).  The
amount of churn here for little benefit seems overwhelming.

Tom