Proposal: Make Eq type class single method
hecate at glitchbra.in
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 :
> 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?
More information about the Libraries