Proposal: Make Eq type class single method

[Hécate]

Hi Joachim,

Thank you for this summary of your findings.

In echo with Tom Ellis' response, I too find the added benefits a tad 
too slim when compared to the changes that will have to be undertaken by 
package authors who have (/=) defined in their instances.
Let's focus on tackling problems that have plagued us for way too long 
instead! :)

Cheers,
Hécate

Le 25/10/2021 à 11:04, Joachim Breitner a écrit :
> Hi,
>
> 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.
>
> With this, I’d like to formally bring this change before the CLC, and
> ask for its support for (or explicit rejection of) this change.
>
> Cheers,
> Joachim
>    
>
-- 
Hécate ✨
🐦: @TechnoEmpress
IRC: Hecate
WWW: https://glitchbra.in
RUN: BSD