Proposal: Make Eq type class single method

[Joachim Breitner]

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 at joachim-breitner.de
  http://www.joachim-breitner.de/