Tue, 23 Oct 2001 18:18:24 +0200
I personally think the inclusion of Float and Double in Enum is an unmitigated disaster.
Enum consists of three separate parts:
(1) succ & pred. These appear for float to correspond to adding or subtracting
1.0. (I am finding this out by testing with ghci; it's not specified where
it should be, in section 6.3.4 of the standard). Because of rounding errors,
succ and pred fail many of the properties for float they have for integers, EG
succ . pred = pred . succ = id
succ x > x
and so on.
succ and pred might actually be USEFUL if instead they represented the next
representable real (with succ (-0.0) = 0.0 I suppose), as it is I don't really
need succ when (+1.0) is clearer and not much longer to type.
(2) toEnum,fromEnum. fromEnum appears to do some unspecified rounding; for GHC
it rounds to 0. toEnum also does rounding, since Float has in some areas
less precision than integers. For example (toEnum 1234567890) :: Float
and (toEnum 1234567891) :: Float appear to be identical. Why we should need
two poorly-specified rounding functions here is beyond me.
(3) enumFrom, enumFromThen and so on, aka arithmetic sequences. These are defined
in terms of equations which work for exact types, but to find out how it actually
works you need to decipher the Haskell code in the prelude, which tells you
the increment is added at each step. Thus the second element of [m,n...]
may not be n, and [x..] will eventually get stuck in a loop.
I think it would be best if we could just get rid of using the Enum instance for
Float and Double, but if not it should be deprecated.