[ketil@ii.uib.no: Re: Enum class]

Dylan Thurston dpt@math.harvard.edu
Thu, 25 Oct 2001 17:27:23 +0900


--9jxsPFA5p3P2qPhR
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Oct 25, 2001 at 10:01:57AM +0200, Ketil Malde wrote:
>=20
> [Heavy snippage and editing]
> >> From: Ketil Malde <ketil@ii.uib.no>
> >> Subject: Re: Enum class
>=20
> >>> i_succ' =3D 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.
>=20
> Uh - I meant wrong in an intuitive way, and I was corrected on the
> grounds that the Prelude defines ... <snippage> ...
> 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.

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.

> 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).

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

Best,
	Dylan Thurston

--9jxsPFA5p3P2qPhR
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE718zrVeybfhaa3tcRAkyxAJ0TdfBXFMoniM22u5iJt5/k42jNPQCeOVmR
UbIYNeGSXAJ2HO2n5UL+fSY=
=hmAf
-----END PGP SIGNATURE-----

--9jxsPFA5p3P2qPhR--