Hi,
Sometimes, /= is semidecidable and == only cosemidecidable. E.g. Exact Real
Arithmetic.
Best,
Jens
On Wed, 20 Oct 2021 at 15:56, Joachim Breitner
Hi,
oh, and I completely forgot to add:
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…
Cheers, Joachim
-- Joachim Breitner mail@joachim-breitner.de http://www.joachim-breitner.de/
_______________________________________________ Libraries mailing list Libraries@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries