Wed, 24 Oct 2001 00:58:17 -0700
I'm filing most of this (useful) discussion about Enum under "ideas for
Enum is a known problem, and when we did the Haskell 98 definition in
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
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
Hmm. If the specification is ok, I'm disinclined to add an
too -- there's every chance I'll get it wrong too!
| * Add definitions for boundedEnumFrom... to the Prelude,=20
| * Split the Enum class into two. =20
Not for Haskell 98, I think. Even the former would break working
that happen to define boundedEnumFrom... Ah well.