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

[Chris Smith]

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