On Tue, 2011-09-20 at 17:39 +0200, Ketil Malde wrote:
You forgot "confusing"?
I didn't forget it; whether it's confusing or not depends on the perspective you're coming from. The kids in my beginning programming class are using Enum (via the list syntactic sugar) on Float and don't get confused... so perhaps we ought to ask what the cause of the confusion is.
Expecting Enum to enumerate all inhabitants of a type seems very reasonable to me, and seems to hold for all non-floating point types.
Floating point (and fixed point, for that matter) types approximate real numbers, which of course have no possible enumeration of all values. Even if you want to say they approximate rational numbers, it remains the case that the rationals have no linearly ordered enumeration of all their values, which would be needed to be compatible with the approximation. It seems to me particularly pointless to define an Enum instance that focuses on, above all else, the inaccuracy of that approximation. Incidentally, you can add Rational to the list of types that define Enum that way and don't enumerate all possible values. And the Haskell Report gives a generic implementation of Enum in terms of Num, which behaves that way. Perhaps I was understating the case in saying the behavior was established but undocumented; rather, it's explicitly documented in the Haskell Report, just not as a requirement for programmer-defined instances of the Num class (because that's not the job of the Report).
Or just avoid Enum, and define "range" or something similar instead.
If Haskell defined list syntax in terms of something that's not called Enum, that would be fine. Renaming is never all that big a deal. But the list sugar is a big deal, and I don't think there's any point at all in leaving the list sugar associated with something as minor as building a representation of the inaccuracy of your approximations. -- Chris