Haskell 98: Enum class
Wed, 24 Oct 2001 07:51:12 -0700
| > 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.)
Lies, all lies. The default methods do not constitute a specification;
in this case at least, they only approximate the truth.
The Report is quite specific about what enumFrom and friends
should do for Integer (Section 3.10). Admittedly, that's a funny place
to look. Maybe I should move that stuff from 3.10 to 6.3.4.
The Report is (regrettably) silent about what the Integer
instances for succ and pred should be, but they should definitely simply
add 1 (resp subtract 1). They should emphatically not use the default
methods. I will add something to that effect in 6.3.4.
However Section 6.3.4 is silent on the question of what succ and pred do
at the end of the range. What is (succ maxInt)? Bizarrely, Appendix
(derived instances of Enum) tells us that that's an error. (Bizarre
this fact belongs in 6.3.4 not in D.2.)
In summary, I propose the following (presentational) changes to the
1. Move specification of enumFrom and friends from 3.10 to 6.3.4
2. Specify that for bounded types, (succ maxBound) and (pred minBound)
3. Specify that succ and pred on numeric types just add/subtract 1
4. Rewrite D.2 to talk about deriving only, not about Enum in general.
5. In Appendix A, the Enum class defn, add comments to explain that the
default methods only work for types whose fromEnum/toEnum range fits=20
Would that at least make the present sitation clear. Acknowledging
that Enum has warty features.