Are Ord and Enum sometimes incompatible in Haskell?

Can Ord and Enum be unambiguous? Why doesn't Enum require Eq ?

+7
source share
3 answers

Enum represents types that can be mapped to / from integers. It says nothing about how to sort these types, just so you can represent them with integers.

Ord is an ordered type. This is different from types that can be matched to integers. For example, you cannot match arbitrary precision floating point values ​​with integers, but you can order them. And while you can technically try to match Floats with integers, no one in their right mind will do this.

As for Eq , Ord requires this because it makes no sense to have a fully ordered data type that does not support equality. However, Enum does not need Eq . Since Enum does not provide any guarantee of the order, it also does not guarantee equality guarantees.

+6
source

There are things that can be listed without a warrant. For example:

 data Color = Red | Green | Blue deriving Enum 

What order should the color have? There is no inherent order, even if colors can be ignored.

There are also things that can be listed but not compared for equality. Floats, for example, have a NaN value that is not equal to anyone. Floats may be listed, however.

+8
source

Although I’m not sure how common this is, I’ve always looked at Enum as a class that describes types with canonical full pre-orders (that is, there may be a loop), so that the sequence of terms β€œbetween” any pair of terms is finite (attested by enumFromTo ).

Ord , on the other hand, describes types with canonical full orders without any requirement that the set of elements between any pair of terms be finite.

+2
source

All Articles