Re: Proposal: Make Eq type class single method

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
>   [email protected]
>   http://www.joachim-breitner.de/
> 
> 
> _______________________________________________
> Libraries mailing list
> [email protected]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>

_______________________________________________
Libraries mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries