[Haskell-cafe] instance Enum Double considered not entirely great?

[Chris Smith]

On Tue, 2011-09-20 at 17:28 -0400, Casey McCann wrote:
> Since removing the instances entirely is
> probably not a popular idea, the least broken solution would be to
> define NaN as equal to itself and less than everything else, thus
> accepting the reality of Ord as the "meaningless arbitrary total
> order" type class I suggested above and leaving Haskell bereft of any
> generic semantic comparisons whatsoever. Ah, pragmatism.

There's nothing *wrong* with pragmatism, but in any case, we seem to
agree on this.  As I said earlier, we ought to impose a (rather
arbitrary) total order on Float and Double, and then offer comparison
with IEEE semantics as a separate set of functions when they are needed.
(I wonder if Ocaml-style (<.) and (>.) and such are used anywhere.)

> It's not clear that Enum, as it stands, actually means anything coherent at all.

It's clear to me that Enum for Float means something coherent.  If
you're looking for a meaning independent of the instance, I'd argue you
ought to be surprised if you find one, not the other way around.  Why
not look for a meaning for Monoid that's independent of the instance?
There isn't one; instead, there are some rules that the instance is
expected to satisfy, but there are plenty of types that have many
possible Monoid instances, and we pick one and leave you to use newtypes
if you wanted a different one.

I'm not saying that Enum must be left exactly as is... but I *am* saying
that the ability to use floating point types in list ranges is important
enough to save.  For all its faults, at least the current language can
do that.  When the solution to the corner cases is to remove a pervasive
and extremely useful feature, I start to get worried!

Yes, I could see (somehow in small steps that preserve backward
compatibility for reasonable periods) building some kind of clearer
relationship between Ord, Enum, and Ix, possibly separating Enum from a
new Range class that represents the desugaring of list ranges, or
whatever... but this idea of "I don't think this expresses a deep
underlying relationship independent of type, so let's just delete it
without regard to how useful it is" is very short-sighted.

-- 
Chris Smith