<div dir="ltr">Something I like about the current definition of Eq is that I can choose which method to implement. If (/=) is more convenient, I implement that one and leave the other as default, and viceversa.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Mo., 25. Okt. 2021 um 16:11 Uhr schrieb Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com">carter.schonwald@gmail.com</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">i agree with Tom and Hecate,<div>more strongly: <a href="https://github.com/ghc/ghc/blob/98aa29d3fe447cce3407e6864b015892244bb475/libraries/ghc-prim/GHC/Classes.hs#L142-L150" target="_blank">https://github.com/ghc/ghc/blob/98aa29d3fe447cce3407e6864b015892244bb475/libraries/ghc-prim/GHC/Classes.hs#L142-L150</a> </div><div>the current definition DOES NOT require defining both. </div><div><br></div><div>as it currently stands, you only need to define one of '==' <b>XOR</b> '/='</div><div><br></div><div>this actually suggests an interesting and DIFFERENT ecosystem improvement, (ignoring IEEE non-signalling NANs),</div><div>namely we add support for XOR to minimal pragma syntax and issue a warning </div><div><br></div><div>perhaps something like adding <b>(XOR "reason String" clauseExpr1 clauseexpr2)</b> ?</div><div><br></div><div>in which case for the Eq the example useage would be something like </div><div><br></div><div>{-# MINIMAL ((== ) || (/=)) & (XOR "it is seldom correct to define both == and /= explicitly, please be careful!" (==) (/=)) #-}</div><div><br></div><div>this also seems like a "newish contributor" ish friendly improvement in our minimal pragma facilities that could be useful for other examples?</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 25, 2021 at 9:29 AM Oliver Charles <<a href="mailto:ollie@ocharles.org.uk" target="_blank">ollie@ocharles.org.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><u></u><div><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="gmail-m_-1687061731779818132gmail-m_3943943038920346198qt"><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" target="_blank">mail@joachim-breitner.de</a><br></div><div> <a href="http://www.joachim-breitner.de/" target="_blank">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" target="_blank">Libraries@haskell.org</a><br></div><div><a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br></div><div><br></div></blockquote><div><br></div></div>_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>