Add Equals to Type.Data.Boolean?

[Cyril Sobierajewicz]

We have Type.Data.Ordering.Equals and Type.Data.Symbol.Equals but no Type.Data.Boolean.Equals.

Is there any reason for not wanting or needing this class?

I assume it would be implemented like this:

class Equals :: Boolean -> Boolean -> Boolean -> Constraint
class Equals lhs rhs out | lhs rhs -> out, lhs out -> rhs, rhs out -> lhs

instance equalsTrueTrue :: Equals True True True
else instance equalsTrueFalse :: Equals True False False
else instance equalsFalseTrue :: Equals False True False
else instance equalsFalseFalse :: Equals False False True

equals :: forall proxy l r o. Equals l r o => proxy l -> proxy r -> Proxy o
equals _ _ = Proxy

[JordanMartinez]

Yes, we should add it for completeness.

However, now that we have polykinds, is it possible for Equals to become polymorphic, so that we don't need an Ordering.Equals or Symbol.Equals?

[Cyril Sobierajewicz]

I don’t think we can have a single polymorphic Equals class: its instance for symbols would overlap the other instances for orderings and booleans!

Also since Boolean has only two inhabitants we can have more functional dependencies (lhs out -> rhs and rhs out -> lhs), allowing the compiler to deduce one of the parameters from the other and the result (which isn’t possible for symbols nor orderings when the result is False).

[JordanMartinez]

Ah, good point.

[JordanMartinez]

#66 wasn't merged because a concrete use case wasn't known at that particular time.