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