Enum class

[George Russell]

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.