On Wed, Oct 20, 2021 at 04:55:15PM +0200, Joachim Breitner wrote:
Am Mittwoch, dem 20.10.2021 um 16:39 +0200 schrieb Joachim Breitner:
If no: would it be worth removing it?
Yes, every change is annoying, but if are going to keep using Haskell the next 30 days, it may pay off? And it might not be too bad: Remove it from base, but teach GHC to not error out if an instance defines (/=), but print a warning and otherwise ignore it. Libraries can remove it if it is defined, which is a backwards-compatible change.
And an (important?) benefit would be that now Eq would then be a single-method class, which are compiled by GHC more efficiently – they essentially _are_ the (==) function, not a tuple of both methods. For something as low-level as (==), this might be measurable…
Since (/=) is an Eq class method it can be implemented on (Int, Int) as (x1, x2) /= (y1, y2) = (x1 /= y1) || (x2 /= y2) If it were not a class method it would have to be implemented as, after inlining (x1, x2) /= (y1, y2) = not ((x1 == y1) && (x2 == y2)) Might not the latter be less efficient, because of the extra `not`? Tom