(I've just wrenched this debate from glasgow-haskell-bugs and hugs-bugs to
haskell; I hope no-one minds.)
Marc van Dongen wrote:
>
> George Russell ([EMAIL PROTECTED]) wrote:
>
> : Marc van Dongen wrote:
> : > Wouldn't that make Enum depend on Ord?
> : > Doesn't seem to make sense if classes are
> : > enumerable but not comparable.
>
> Of course above I should have said orderable in stead of comparable.
>
> : What examples are there of types for which it would be sensible to implement
> : Enum but not Ord? The concept rather puzzles me. In particular, suppose you
> : don't have an ordering on the pair (a,b). How do you propose to compute
> : [a..b]
>
> data Human = Woman | Man
Hmm maybe. But then are you going to make succ Woman = Man or succ Man = Woman??
It seems to me that in any case you are going to upset people.
Humans are a special case because there are only two ways of ordering the
sexes, and both are controversial. If we have
data Colour = Red | Blue | Yellow
and want to make Colour an instance of Enum, then to consistently define [..]
you need to make arbitrary choices. If you're going to arbitrarily choose an
enumeration it doesn't seem unreasonable to me to arbitrarily choose an ordering
as well.
