[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

Dylan Thurston <dpt@math.harvard.edu> writes:

On Thu, Oct 25, 2001 at 10:01:57AM +0200, Ketil Malde wrote:

I think it's clear from the thread that the language designers did _not_ intend this, and that one should not use the default instances for the standard numeric classes. See Simon Peyton-Jones' recent post.

Yeah, I just read it. Unfortunately, I got this thread first :-)

I agree that Enum instances for Float/Double are not likely to be useful.

From a gut feeling, I could see a use for expressions like

[1.5, 1.6..] and [1.5, 1.6..2.0] (i.e. enumFromThen and enumFromThenTo) but enumFrom and enumFromTo making list of rounded integers seems strange to me. It seems to me that enumFromThen and -To could be implemented something like: enumFromThen beg next = beg : enumFromThen next (next+delta) where delta = next-beg similarly for enumFromThenTo, of course. i.e. depending only on functionality found in Num. Why not put these functions there, and remove Float and Double as Enum instances? What am I missing? -kzm -- If I haven't seen further, it is by standing in the footprints of giants