<!DOCTYPE html><html><head><title></title><style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>I'd like to also add that there is another benefit - correctness.<br></div><div><br></div><ul><li>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.<br></li></ul><div><br></div><div>On Mon, 25 Oct 2021, at 2:22 PM, Joachim Breitner wrote:<br></div><blockquote type="cite" id="qt" style=""><div>Hi,<br></div><div><br></div><div>ah, yes, let me summarize my main motivation (perf benefits were just a<br></div><div>side-benefit I was hoping for):<br></div><div><br></div><div>You can’t implement (/=) faster than (==) (up to, in the worst case,<br></div><div>the cost of a single `not`, which often gets optimized away anyways). <br></div><div><br></div><div>As such, having (/=) in Eq was a (small) mistake back then, and it’s<br></div><div>worth fixing.<br></div><div><br></div><div>There is one time cost of asking developers to _remove_ code. But code<br></div><div>that was probably not worth writing in the first place! And I don’t<br></div><div>blame them, the Eq class _invites_ writing that code.<br></div><div><br></div><div>Then the benefits are twofold:<br></div><div> <br></div><div>* No more awkwards explanations about silly things in the likely first<br></div><div> type class that developers care about.<br></div><div><br></div><div>* Less code to read, maintain, compile in all the libraries that _do_<br></div><div> define (/=) right now.<br></div><div><br></div><div>* Devs who instantiate Eq in the future will not be tricked into <br></div><div> wondering if they need to implement (/=) and why.<br></div><div><br></div><div>So even if “helps teaching beginners” doesn’t beat “having to bug<br></div><div>maintainers”, then maybe the second point (“saving all develpers time<br></div><div>and effort in the future”) does?<br></div><div><br></div><div>Cheers,<br></div><div>Joachim<br></div><div>-- <br></div><div>Joachim Breitner<br></div><div> <a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</a><br></div><div> <a href="http://www.joachim-breitner.de/">http://www.joachim-breitner.de/</a><br></div><div><br></div><div><br></div><div>_______________________________________________<br></div><div>Libraries mailing list<br></div><div><a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br></div><div><a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br></div><div><br></div></blockquote><div><br></div></body></html>