Christian Sievers wrote:
> Hello, this is about a change in the prelude I'd like to suggest.
>
> The following is obviously not what one would expect:
>
> Prelude> succ 10000000000::Integer
>
> Program error: {primIntegerToInt 10000000000}
>
> However, with the prelude defining succ to be
>
> succ, :: Enum a => a -> a
> succ = toEnum . (+1) . fromEnum
>
> we can't hope for anything better.
>
> My suggestion is to make succ a member function of class Enum, with
> the old definition as default, so that the instance Enum Integer
> can define it to be simply (+1).
>
> Another example is
> data Nat = Zero | Succ Nat
> where succ=Succ is not only more natural, but also much more
> efficient.
>
> Of course the same holds for pred.
>
> What do you think?
> Are there any drawbacks?
> Could it be like this in standard haskell?
I agree, in fact, I'd go one stronger. I'll propose that `fromEnum' and
`toEnum' be taken out, since clearly not all enumerable types are
subtypes of Int (as you point out, Integer leaps immediately to mind).
As an experiment, a little while back,I modified the Prelude to use an
Enum class that included `succ' and `pred', but eliminated `fromEnum'
and `toEnum'. I then had to eliminate all uses of `fromEnum' and
`toEnum'. I found that, in every case, `fromEnum' and `toEnum' were
used at specific types (mostly Char), and popped in the suitable
type-specific replacement. I also had to change hugs to `derive' `succ'
and `pred' instead of `fromEnum' and `toEnum', but this wasn't
difficult.
This certainly makes the Enum class cleaner conceptually, and I can't
think of any drawbacks, except for concern about legacy code (I love
that concept for a young language like Haskell ;-).
--Jeff
