I'm filing most of this (useful) discussion about Enum under "ideas for Haskell 2". Enum is a known problem, and when we did the Haskell 98 definition in the first place there were various proposals for cleaning it up, but (as the discussion indicates) it's hard to decide what the Right Thing is, so it ended up as you see it. Jan-Willhem comes closest to making concrete proposals related to the Revised Haskell 98 story, so I want to comment on them: | * In the report, give clear and explicit definitions of | enumFrom... for Float and Double. This could be done right now. | The toughest part is deciding what the behavior at extremes should | be; any behavior is bad, and so picking one with appropriate caveats | should be just fine. I don't foresee agreement on which bad | behavior is appropriate. The Report Section 6.3.4 (about Enum) refers back to Section 3.10 for semantics for enumFrom etc. There you'll find a specification for what they mean, including Float and Double. If I can improve the wording I'd be glad to do so, but it does look defined to me. | * Get rid of the useless (and in truth actively dangerous) default | methods for enumFrom... and kin. This could be done now, I think. I can see the point here, but that would break working programs. I'd be happy to add a comment with the default methods to say that they only work for types that map into Int nicely. | * Definitions of enumFrom... for Int which deal gracefully with | overflow might be a nice addition to the report as people get them | wrong. Hmm. If the specification is ok, I'm disinclined to add an implementation too -- there's every chance I'll get it wrong too! | * Add definitions for boundedEnumFrom... to the Prelude, | | * Split the Enum class into two. Not for Haskell 98, I think. Even the former would break working programs that happen to define boundedEnumFrom... Ah well. Simon