I'd like to also add that there is another benefit - correctness. * Eq is easier to get right/harder to get wrong. Currently if you hand roll Eq, you could potentially implement both == and /=, but get one or the other wrong. With only == as a method, as long as you get that right, you are guaranteed that /= is also right. On Mon, 25 Oct 2021, at 2:22 PM, Joachim Breitner wrote:
Hi,
ah, yes, let me summarize my main motivation (perf benefits were just a side-benefit I was hoping for):
You can’t implement (/=) faster than (==) (up to, in the worst case, the cost of a single `not`, which often gets optimized away anyways).
As such, having (/=) in Eq was a (small) mistake back then, and it’s worth fixing.
There is one time cost of asking developers to _remove_ code. But code that was probably not worth writing in the first place! And I don’t blame them, the Eq class _invites_ writing that code.
Then the benefits are twofold:
* No more awkwards explanations about silly things in the likely first type class that developers care about.
* Less code to read, maintain, compile in all the libraries that _do_ define (/=) right now.
* Devs who instantiate Eq in the future will not be tricked into wondering if they need to implement (/=) and why.
So even if “helps teaching beginners” doesn’t beat “having to bug maintainers”, then maybe the second point (“saving all develpers time and effort in the future”) does?
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