[Heavy snippage and editing]
From: Ketil Malde <ketil@ii.uib.no> Subject: Re: Enum class
i_succ' = succ i' -- ghc : 2147483648 -- hugs: -2147483648
I think Hugs is wrong. Integer shouldn't wrap.
"Sigbjorn Finne" <sof@galconn.com> writes:
Hugs is indeed wrong, I've checked in the same (obvious) fix that was made to GHC's Enum Integer instance a long time ago.
Uh - I meant wrong in an intuitive way, and I was corrected on the grounds that the Prelude defines: class Enum a where succ, pred :: a -> a toEnum :: Int -> a fromEnum :: a -> Int enumFrom :: a -> [a] -- [n..] enumFromThen :: a -> a -> [a] -- [n,n'..] enumFromTo :: a -> a -> [a] -- [n..m] enumFromThenTo :: a -> a -> a -> [a] -- [n,n'..m] and that the .. "operator", as well as succ and pred is defined in terms of toEnum and fromEnum: -- Minimal complete definition: -- toEnum, fromEnum succ = toEnum . (+1) . fromEnum pred = toEnum . (subtract 1) . fromEnum enumFrom x = map toEnum [fromEnum x ..] enumFromTo x y = map toEnum [fromEnum x .. fromEnum y] enumFromThenTo x y z = map toEnum [fromEnum x, fromEnum y .. fromEnum z] (All right off the web pages at Haskell.org) So apparently, it was the intention of the language designers that "infinite" lists defined by [b..] and the so-called succ only go from 2G long before they wrap, since toEnum and fromEnum maps to Ints and not Integers. There's also been a longish thread about the fun consequences for floating point numbers, I can try to summarize if necessary. I, being a mere lay programmer, find it quite surprising that "succ" returns the next higher integer for positive floats, but the next higher *plus one* for negatives. Or that [a..b] produces a set of numbers outside the specified range (and indeed that these are defined at all for floating point numbers). -kzm -- If I haven't seen further, it is by standing in the footprints of giants