Proposal: Remove method (/=) from class Eq

[nomeata]

@Bodigrim suggested I take the proposal that I recently submitted to libraries@ here, to play guinea pig for this process.

What

I suggest to change

class Eq a where (==), (/=) :: a -> a -> Bool

to

class Eq a where (==) :: a -> a -> Bool

and turn (/=) into a normal function.

Why

• If we’d define class Eq now, we wouldn’t include (/=).

  In general, the motivations for “redundant” methods with default implementation could be

  • The alternative method can be implemented more efficiently than the “main” method.
  • If the “main” method has a default implementation, too: The alternative method is easier or more natural to implement.

  Here, neither of these apply (justification below), and “fixing” this is worth it, for the following reasons:

• Teaching: The Eq class is often the first, or one of the first, type classes that beginners will face. This means that educators have to explain what default methods are and why they exist, and then have to apologetically say “but this doesn't really apply here, sorry”. (The Ord class is much better in that regard, for example (<=) can be implemented more efficiently than compare.)

• Development cost and effort: Every developer implementing an Eq instance will have to make a decision whether to instantiate (/=). They have more documentation to read. And precisely because (/=) doesn’t really make sense here, they might have to think extra long about whether to instantiate (/=) or not.

  Removing the method will save some time of future developers.

• Similarly. whenever someone reads code and comes across an Eq instance with (/=) defined explicitly they have extra work to do, and think “Why was this defined?”, “Is it lawful?”. Removing the method from the class alltogether will mean library code gets simpler and easier to read.

  Removing the method will cause libraries to have less code, not more.

• Lawfulness. Eq says x /= y = not (x == y), but that is only true if everybody plays by the rules. By having (/=) it is possible for instances to be unlawful (intentionally or accidentally), for little gain.

  Removing the method will guarantee that equation.

• Code changes are backward compatible. This change will require some library maintainers to change their code. But the code change is simple (remove the method, possibly adjust the import statement), and is compatible with old versions of base. No complex migration strategy, no CPP needed.

• Performance gains (very minor). Single method classes are currently represented more efficiently in GHC. In some higher-order cases removing the method might speed up programs. Also, compiling base and libraries with Eq instances and creating haddocks gets (very slightly) faster, because there is less to do.

• Implementation in base is simple: See https://gitlab.haskell.org/ghc/ghc/-/merge_requests/6793.

Why not (and rebuttals)

Most of these are taken from the libraries thread; rebuttals are mine.

• (/=) can sometimes be implemented more efficiently.

  Rebuttal: Beyond the cost of a single call to not, which GHC often optimizes away anyways, this is not possible (for law-abiding instances.)

• (/=) can sometimes be more natural to implement.

  Rebuttal: Relatively unlikely, and possibly more error-prone and harder to read, due to the many negations.

• There is a one-time cost for affected library authors, and it’s not worth it.

  A mildly naive hackage search shows 131 affected packages.

  Rebuttal: The change is easy, mechanical and backward compatible. But more important: Because this change simplifies both base and the code of affected libraries, it will pay off eventually, because of all the work we (as the community) save over time by no longer having to think about (/=). In fact, the evidence that 131 packages’s authors manually (and, in most cases, pointlessy) wrote an (/=) means this proposal will save the next 131 packages’s authors, and beyond, unnecessary work.

• Some libraries use this to write unlawful instances, e.g. Non-lawful Eq Null instance? haskellari/postgresql-simple#78.

  Rebuttal: Don’t write unlawful instances. If you need (/=) to behave differently than the negation of (==), Eq is the wrong type class. I understand that this is a bit harsh, as the libraries authors might have reasons to break the lawfulness.

• RULE matching on single method class methods doesn't work reliably, but does work for other classes.

  _ Rebuttal_: I consider that a bug in GHC and would fix one way or another before enacting this proposal.

• We should clean up the type class hierarchy in a bigger way.

  Rebuttal: Maybe, but that should not doing this small cleanup proposed here.

[djduke]

I'm -1 on this change. I've >10 years experience teaching Haskell and its never been an issue with teaching.
On the contrary Eq is a simpler case studies to introduce laws, rather than wait until students encounter
Applicative etc
I've sometimes found it simpler to think terms of dfining /=, I've never worried about performance from
this issue, ther eare usually lower hanging fruits elsewhere.

[isovector]

I'm +1. This is a fantastic simplifying change. There's no reason not to do this, other than extremely trivial breakages. And I would really like to live in a world where we don't let the burden of already-written code get in the way of turning Haskell into the language we want it to be.

[cartazio]

this breaks code for no reason. Lets not touch this till we have better support for warning about redundantly defined type class methods such as having a "XOR" warning minimal pragma change such as I suggest in https://mail.haskell.org/pipermail/libraries/2021-October/031490.html

[mixphix]

I'm +1 on this. x /= y = not (x == y) can and should be defined outside of the class.

As it stands, Haskell's type class system does not have a framework for "class laws": at best, they are guidelines for how types fitting that class should behave. There is no way within a class' definition to guarantee that only those types with lawful implementations should be bestowed the class. The burden lies on the library designer to help guide their users away from footguns; unlawful instances are some of those. By removing (/=) from the class definition and forcing users only to write one method, the opportunity for bugs to arise diminishes and they are easier to spot when they do.

Also, who really writes Eq instances by hand in production code, anyway? Be honest. The vast, vast majority of users derive Eq for the datatypes they define. And by making Eq a single-method typeclass, this deriving gets even easier. You still get (/=) for free, it just so happens it's not in the class definition.

Thanks for raising this issue, @nomeata!

[Bodigrim]

To facilitate internal CLC discussions, I’d like to gather some additional input:

1. If we were to design Haskell from scratch today, would we prefer one or two members of Eq? Are there arguments to prefer two today?
2. Does this change affect educational materials or text books? Could anyone bring specific examples?
3. Are proponents of the change willing to facilitate ecosystem’s migration by raising PRs to affected libraries? Are maintainers willing to accept such PRs? CC @phadej for postgresql-simple, @paul-rouse for mysql-simple, @treeowl for containers.
4. What is an impact of this change on GHC and compilation times? CC @AndreasPK.

[nomeata]

Does this change affect educational materials or text books? Could anyone bring specific examples?

Concrete example: In a tutorial of my own I explain the concept of default methods when I introduce the Eq class. This section would change, and default implementations only explained later when they first come up. (Unsurprisingly,) I would welcome that change; it would allow me introduce default methods with a type class where they make more sense (e.g. Ord).

[phadej]

1 If we were to design Haskell from scratch today, would we prefer one or two members of Eq? Are there arguments to prefer two today?

I'd probably flip a coin

• purescript doesn't have /= in the type-class https://pursuit.purescript.org/packages/purescript-prelude/3.1.0/docs/Data.Eq
• plutus neither https://github.com/input-output-hk/plutus/blob/master/plutus-tx/src/PlutusTx/Eq.hs
• nor scala's cats: https://typelevel.org/cats/typeclasses/eq.html
• idris does https://docs.idris-lang.org/en/latest/tutorial/interfaces.html#default-definitions

2 Does this change affect educational materials or text books? Could anyone bring specific examples?

Hutton's Programmin gin Haskell says in 3.9 basic classes section

Eq - equality types

... using following two methods

(==) :: a -> a -> Bool
(/=) :: a -> a -> Bool

However, the presentation in that chapter just tells these functions
exist, it doesn't yet speak about defining own instances.

I don't think that would trap future readers of an old edition book who use newer GHC

3 Are proponents of the change willing to facilitate ecosystem’s migration by raising PRs to affected libraries?

See below. Though I'm not proponent nor opponent of this change, I just want
to dismiss the narrative that a lot stuff would break.
I didn't believe it. Judge yourself.

Are maintainers willing to accept such PRs?

I'd accept a PR, though I'd just do it myself during the usual new-GHC-support
work. (In my case, to have a comparison example, removal of Option generates/d more
work).

---

I built Stackage LTS-18.8 set (which I had around for other experiment).
Out of ~2600 packages (snapshot is slightly larger, but I left out some packages
needing native dependencies etc.)
the following ~45 needed some changes:

packages: attoparsec-0.13.2.5/
packages: backprop-0.2.6.4/
packages: basement-0.0.12/
packages: basic-prelude-0.7.0/
packages: butcher-1.3.3.2/
packages: clash-lib-1.4.3/
packages: clash-prelude-1.4.3/
packages: clientsession-0.9.1.2/
packages: compdata-0.12.1/
packages: compensated-0.8.3/
packages: conduit-1.3.4.1/
packages: DBFunctor-0.1.2.1/
packages: dimensional-1.4/
packages: eventstore-1.4.1/
packages: fb-2.1.1/
packages: geojson-4.0.2/
packages: ghc-lib-parser-8.10.7.20210828/
packages: haskell-gi-base-0.25.0/
packages: HaskellNet-0.6/
packages: hOpenPGP-2.9.5/
packages: hybrid-vectors-0.2.2/
packages: intro-0.9.0.0/
packages: io-streams-1.5.2.1/
packages: loc-0.1.3.10/
packages: mixed-types-num-0.5.9.1/
packages: multistate-0.8.0.3/
packages: numbers-3000.2.0.2/
packages: numeric-prelude-0.4.3.3/
packages: postgresql-libpq-0.9.4.3/
packages: postgresql-simple-0.6.4/
packages: prelude-compat-0.0.0.2/
packages: primitive-addr-0.1.0.2/
packages: protolude-0.3.0/
packages: relude-0.7.0.0/
packages: sbv-8.15/
packages: semirings-0.6/
packages: singletons-2.7/
packages: snap-core-1.0.4.2/
packages: sqlite-simple-0.4.18.0/
packages: string-class-0.1.7.0/
packages: tfp-1.0.2/
packages: type-level-natural-number-2.0/
packages: type-natural-1.1.0.0/
packages: unboxing-vector-0.2.0.0/
packages: uncertain-0.3.1.0/
packages: unification-fd-0.11.1/
packages: vector-0.12.3.0/

(and mysql-simple which I didn't build).

Most changes are oneliners. Either removing explicit /= definition,
or adding /= import.

I can upload patches somewhere, if anyone is interested to take a closer look
at them. (I won't submit them upstream, though some are probably good even
without the change going in, i.e. removing unnecessary definitions of /=).

Few packages are more interesting:

---

clash-prelude

This is interesting application.
I'd ask if the change makes things less convenient.

The /= is defined to be some "primitive" (which is NOINLINE, and in future
OPAQUE I suppose) for which Clash looks in the Core. That's my
understanding.

---

alternative or special purpose preludes:

protolude, basic-prelude, haskell-gi-base, relude needed an amendment to keep the re-export list intact.
Similarly basement, though it also needed a fix in itself.

---

GHC (like) code: clash-lib and ghc-lib-parser, "I have seen this code".

---

complicated /= example

https://hackage.haskell.org/package/numbers
package illustrates the "are == and /= compatible, or do they differ?"
problem.

data Interval a = I a a

ival :: (Ord a) => a -> a -> Interval a
ival l h | l <= h = I l h
         | otherwise = error "Interval.ival: low > high"

instance (Ord a) => Eq (Interval a) where
    I l h == I l' h'  =  l == h' && h == l'
    I l h /= I l' h'  =  h < l' || h' < l

---

https://hackage.haskell.org/package/DBFunctor package has:

-- | Definition of the Relational Data Type. This is the data type of the values stored in each 'RTable'.
-- This is a strict data type, meaning whenever we evaluate a value of type 'RDataType', 
-- there must be also evaluated all the fields it contains.
data RDataType = 
        RInt { rint :: !Integer }
      | RText { rtext :: !T.Text }
      | RUTCTime { rutct :: !UTCTime}
      | RDate { 
                rdate :: !T.Text
               ,dtformat :: !Text  -- ^ e.g., "DD\/MM\/YYYY"
            }
      | RTime { rtime :: !RTimestamp  }
      | RDouble { rdouble :: !Double }
    -- RFloat  { rfloat :: Float }
      | Null



-- | We need to explicitly specify equation of RDataType due to SQL NULL logic (i.e., anything compared to NULL returns false):
-- @
-- Null == _ = False,
-- _ == Null = False,
-- Null /= _ = False,
-- _ /= Null = False.
-- @
-- IMPORTANT NOTE:
-- Of course this means that anywhere in your code where you have something like this: 
-- @
-- x == Null or x /= Null, 
-- @
-- will always return False and thus it is futile to do this comparison. 
-- You have to use the is 'isNull' function instead.
--
instance Eq RDataType where

    RInt i1 == RInt i2 = i1 == i2
    -- RInt i == _ = False
    RText t1 == RText t2 = t1 == t2
    -- RText t1 == _ = False
    RDate t1 s1 == RDate t2 s2 = toRTimestamp (unpack s1) (unpack t1) == toRTimestamp (unpack s2) (unpack t2)   -- (t1 == t1) && (s1 == s2)
    -- RDate t1 s1 == _ = False
    RTime t1 == RTime t2 = t1 == t2
    -- RTime t1 == _ = False
    RDouble d1 == RDouble d2 = d1 == d2
    -- RDouble d1 == _ = False
    -- Watch out: NULL logic (anything compared to NULL returns false)
    Null == Null = False
    _ == Null = False
    Null == _ = False
    -- anything else is just False
    _ == _ = False

    Null /= Null = False
    _ /= Null = False
    Null /= _ = False
    x /= y = not (x == y) 

I.e. it's a DSL trying to emulate SQL-like processing in Haskell.
Not able to do weird thing SQL does with NULl equality would not be nice.
(a lot more inconvenient then for postgresql-simple, where I actually have
no idea what Eq Null instance is useful for).

However, when removing the /= none of the tests of DBFunctor failed.

---

• Oleg

[paul-rouse]

It would be good to get away from the blatantly unlawful instance in mysql-simple! This predates my time as maintainer, so I can only assume the idea was along the lines of the comment in DBFunctor mentioned above. However, it is a poor reflection of modern SQL semantics, and could be very confusing. I would probably just remove the Eq instance on Null, but it is, unfortunately, exposed to users of the library. I doubt if anybody actually uses it, and I've checked that persistent-mysql doesn't, but it's possible that something somewhere would break (I haven't yet tried compiling all of stackage against this change).

Exactly the same code appears in postgresql-simple, so I assume the same applies there.

[phadej]

However, it is a poor reflection of modern SQL semantics

The poorness there is try to model 3VL with two-valued Bool. But I think 3VL way of presenting the NULL comparisons is not particularly new.

https://en.wikipedia.org/wiki/Null_(SQL)#Comparisons_with_NULL_and_the_three-valued_logic_(3VL)

[AndreasPK]

In terms of performance I would expect for real world code: * A very very small compile time benefit most of the time. * No runtime difference for most runtime relevant use cases. * A small to moderate improvement in runtime (not allocation) in some edge cases.   In particular it should only make a difference for code which is not specialized *and***uses the class method lazily or uses both methods. So from a performance PoV, if we were to design it today there would be a reason to have it be a single method. But it's unclear if it's worth breaking packages now for the small benefit it provides. Am 27/10/2021 um 19:45 schrieb Bodigrim:

…

To facilitate internal CLC discussions, I’d like to gather some additional input: 1. If we were to design Haskell from scratch today, would we prefer one or two members of |Eq|? Are there arguments to prefer two today? 2. Does this change affect educational materials or text books? Could anyone bring specific examples? 3. Are proponents of the change willing to facilitate ecosystem’s migration by raising PRs to affected libraries? Are maintainers willing to accept such PRs? CC @phadej <https://github.com/phadej> for |postgresql-simple|, @paul-rouse <https://github.com/paul-rouse> for |mysql-simple|, @treeowl <https://github.com/treeowl> for |containers|. 4. What is an impact of this change on GHC and compilation times? CC @AndreasPK <https://github.com/AndreasPK>. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#3 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABJ65ZWUO6ZWCLDJSM4IMD3UJBCGJANCNFSM5GZ2YRQQ>. Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[Bodigrim]

CC @christiaanb for clash-prelude, @nkarag for DBFunctor.

[Icelandjack]

Using type class backends we could transparently evolve Eq to BackendEq with only one method

[phadej]

Using type class backends we could transparently evolve Eq to BackendEq with only one method

Something like Eq should be a simple as can be imaginable. Original motivation says:

Teaching: The Eq class is often the first, or one of the first, type classes that beginners will face.

[gwils]

I find it hard to form a particularly strong opinion on this either way. It seems like a fairly minor breakage for very minor wins. Some thoughts:
I don't weight teaching very heavily in decision-making about Prelude. I think most educational material would be better served defining a custom prelude, with less polymorphic types, fewer and simpler classes, etc. I'm also perfectly happy to tell students useful lies, for example, I could just present Eq as having one method, and students writing their own instances would be able to do so happily without knowing (/=) is a class method, or even exists!
I'm somewhat sympathetic to the argument that a single method makes law-breaking instances harder, but Eq is rather weak in its laws; in deference to the practically defunct Haskell Report, the Eq laws are explicitly merely "encouraged" (if you'll allow me to side-step Melanie's point that all laws in Haskell are effectively suggestions anyway). I would be more sympathetic to this change if we took a firmer stance on Eqs lawfulness.
Inequality checks are available as an instruction for some types, aren't they? Wouldn't that mean some types will have worse performance with this change (an unnecessary function call to not vs. a single instruction). I confess I'm not very knowledgeable at that level of abstraction.

Right now I'm a very weak -1 on this.

[int-index]

As a Haskell user I probably wouldn’t notice this (I always derive Eq), but back when I was learning Haskell I thought it was pretty neat that the language doesn’t take a stance whether == or /= is the fundamental operation. It’s a nice way to introduce the notion of minimal complete definition (i.e. define a method of your choice and get the other one for free).

Really, why is your proposal to remove /= and keep == rather than to remove == and keep /=? What makes one more fundamental than the other? I used to find it quite elegant that we don’t have to make these arbitrary choices (nowadays I don’t care).

To summarise, I’m leaning slightly against this proposal, but wouldn’t lose my sleep over it.