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