Proposal: Make Eq type class single method

Hécate hecate at
Mon Oct 25 16:06:46 UTC 2021

Hi Joachim :)

I will have to express a friendly but firm disagreement on the argument of a
"one time cost".
You will also have to open PRs for every library, change pedagogical 
broadcast those changes to developers, and provide scripts for code-modding
tools in order to automate this on proprietary codebases.


If you really want to break a bunch of things and fix mistake of the past,
I would suggest to really go for the throat and have PartialEq, 
PartialOrd, Eq, and Ord

We could finally get rid of the Eq instance for the various IEEE types 
like Double, and promote
property testing to the wider public to verify that the laws are indeed 
respected by the implementations.

module NewClasses where

import Prelude hiding (Eq(..), Ord(..))

-- | Equality comparisons which are partial equivalence relations.
class PartialEq a where
   (==) :: a -> a -> Bool

-- | Equality comparisons which are equivalence relations.
-- It is laws-only and manual implementations would be
-- verified through property testing.
class PartialEq a => Eq a

-- | Partial order
class PartialEq a => PartialOrd a where
   compare' :: a -> a -> Maybe Ordering
   (<) :: a -> a -> Bool
   (<=) :: a -> a -> Bool
   (>) :: a -> a -> Bool
   (>=) :: a -> a -> Bool

-- | Total order
class (PartialOrd a, Eq a) => Ord a where
   compare :: a -> a -> Ordering
   max :: a -> a -> a
   min :: a -> a -> a


Le 25/10/2021 à 15:22, Joachim Breitner a écrit :
> 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

Hécate ✨
🐦: @TechnoEmpress
IRC: Hecate

More information about the Libraries mailing list