On 2007-04-18, Isaac Dupree
(Float and Double *aren't* in Bounded. Then again, Haskell98 doesn't require them to contain non-_|_ values of +-infinity.)
And they're only in Enum to support the [a..b] syntax, whose semantics can't really sanely be supported for Float and Double anyways.
Furthermore, there are bounded things that aren't enumerable anyway (I think) (such as some lattices), so it would be odd to add that restriction just because the type might also be in Prelude.Enum.
I'd really like to see one. Unless you're just talking about a set with a partial order, in which case, yes, many are bounded. e.g. reals in [0, 1], as when being used for probabilities.
Rather, I would ask "Must any inhabitant of a type in Enum be reachable by pred or succ from an arbitrary inhabitant of the type?"
That would make sense to me (when restricted to non-bottom inhabitants), and is essentially the objection that many have to Float and Double being in Enum.
For example, I could declare an instance of Enum that contradicted that: data Something = Some Integer | Another Integer where pred and succ always stayed within the same constructor, and for fromEnum/toEnum I would just find some way to encode some common (i.e. relatively small magnitude, just as the usual instance Enum Integer is limited this way) values of Something into an Int. Or are fromEnum/toEnum supposed to obey some sort of properties, when they are defined, relative to the rest of the methods? I would guess not, given the comment - -- NOTE: these default methods only make sense for types - -- that map injectively into Int using fromEnum - -- and toEnum. (hugs: fromEnum (2.6 :: Double) ---> 2)
Cheers, Isaac
The default implementation for the class assumes fromEnuw (succ x) = 1 + fromEnum x and similar things. That's a pretty strong argument that all types should obey that. -- Aaron Denney -><-