Alas, it seems to me Enum is really two classes rather unfortunately lumped together:
Correspondence with Int: > class Enum a where > succ, pred :: a -> a > toEnum :: Int -> a > fromEnum :: a -> Int Arithmetic series-like enumeration: > class Enum a where > enumFrom :: a -> [a] -- [n..] > enumFromThen :: a -> a -> [a] -- [n,n'..] > enumFromTo :: a -> a -> [a] -- [n..m] > enumFromThenTo :: a -> a -> a -> [a] -- [n,n'..m] Having recently had to tweak prelude definitions of all of the above, I can personally testify that the situation is not a happy one: We can't meaningfully define correspondence with Int for type Integer, much less Float, Double, etc. The default enumFrom... use toEnum on Int sequences, and as far as I can tell are no use to anyone; Bounded types must close off the ends of the enumeration at minBound and maxBound, and unbounded types won't fit into an Int. So, what's to be done? * 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. Definitions for the methods in the first category might be nice, too. Perhaps they should signal an error. I'm clueless as to whether pred and succ just add/subtract 1 or whether they ought to round as well. * Get rid of the useless (and in truth actively dangerous) default methods for enumFrom... and kin. This could be done now, I think. * Definitions of enumFrom... for Int which deal gracefully with overflow might be a nice addition to the report as people get them wrong. The Feb. 2000 release of hugs, for example: Prelude> [(maxBound::Int)-2..maxBound] [2147483645,2147483646,2147483647,-2147483648,-2147483647,-2147483646,-2147483645, etc... [GHC appears to do it right, I have no idea about current hugs or nhc versions.] * Add definitions for boundedEnumFrom... to the Prelude, or perhaps to a library. This might or might not be a big change for Haskell 98; I forget where Simon PJ's drawn the line. It does reflect reality, though. * Split the Enum class into two. Possibly "correspondence with Int" belongs in "Bounded"---but it depends what you think "Bounded" means. Int64 and Word probably don't fit the model too well. In any case, this can't really be a revision to Haskell 98; it needs to be thought about in future Haskell versions. What say others? Is this sensible? Or have I let my recent frustrations take hold? -Jan-Willem Maessen Eager Haskell Project [EMAIL PROTECTED] _______________________________________________ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell