[ketil@ii.uib.no: Re: Enum class]
Ketil Malde
ketil@ii.uib.no
25 Oct 2001 10:01:57 +0200
[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