| > i_succ' = 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 = toEnum . (+1) . fromEnum | This is confirmed by the description of the semantics in | 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 have 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 D.2 (derived instances of Enum) tells us that that's an error. (Bizarre because this fact belongs in 6.3.4 not in D.2.) In summary, I propose the following (presentational) changes to the Report. 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) are errors. 3. Specify that succ and pred on numeric types just add/subtract 1 (subject to (2) above. 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 inside Int. Would that at least make the present sitation clear. Acknowledging that Enum has warty features. Simon