
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