Wed, 24 Oct 2001 13:53:54 +0100
> > i_succ' =3D succ i'
> > -- ghc : 2147483648
> > -- hugs: -2147483648
> -- nhc98: -2147483648
> -- hbc: -2147483648
> > I think Hugs is wrong. Integer shouldn't wrap.
> (Actually, ghc is `wrong': hbc, hugs and nhc98 match the Report's
> specification here: succ =3D toEnum . (+1) . fromEnum
> This is confirmed by the description of the semantics in=20
> section 3.10.)
Indeed. But the default definitions of enumFrom & friends also don't
make much sense for Integer. With nhc98, which presumably is using the
default definitions from the report:
Prelude> [2147483647 .. 2147483649]
according to the report, this should yield an error (section 6.3.4
states that fromEnum should report an error if its argument is out of
range). Both behaviours seem less than useful to me. GHC returns
[2147483647, 2147483648, 2147483649], which is also wrong.
Is there a good reason why toEnum & fromEnum convert to/from Int rather