Relax the restriction on Bounded derivation

[Aaron Denney]

On 2007-04-18, Isaac Dupree <isaacdupree at charter.net> wrote:
> (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
-><-