Proposal: Make Eq type class single method

[Hécate]

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 
material,
broadcast those changes to developers, and provide scripts for code-modding
tools in order to automate this on proprietary codebases.

Side-proposal

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


Cheers,
Hécate

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
WWW: https://glitchbra.in
RUN: BSD