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

[Chris Smith]

On Tue, 2011-09-20 at 16:22 -0400, Jake McArthur wrote:
> This makes me wonder if maybe the reason this discussion is happening
> at all is that we don't have a well-defined meaning for what Enum
> *is*.

Certainly, we don't have a type-independent definition for Enum.  I'm
not sure whether it's possible to obtain that or not.  Keep in mind that
for plenty of common type classes, this is not possible.  For example,
consider Monoid.  By writing a monoid instance, you're making the rather
ridiculous claim that you are specifying *the* way to define a Monoid on
that type, when of course there are more than one, and there's no formal
way to say what that Monoid should do independent of whatever operation
happens to be most commonly used for combining values of that type.
Same for many Functor or Applicative or Monad instances.

So yes, we don't know how to define a type-independent meaning... but
I'm completely sure that it would be a mistake to start dropping useful
things from Haskell just because we're unable to put our finger on a
formalism for describing them precisely without assigning type-dependent
meanings.

> What exactly does Enum enumerate?

I'd say that just like the case with Monoid, Enum means whatever it's
most useful for it to mean with respect to some particular type.  We
could probably be a little more specific with laws that we expect the
instance to follow, such as:

    enumFromTo a b == enumFromThenTo a (succ a) b

and so on.  But it's not always possible to define a notion

> To me, the list syntax sugar looks like I'm specifying bounds, so it
> makes sense to include all values within those bounds (and honestly,
> having instances for Float, Double, and Rational sounds like a mistake,
> given this)

It's unclear to me how you get from (has bounds) to (must include
*everything* in those bounds).  I'd definitely agree that for instances
of Enum that are also instances of Ord, you'd expect (all (>= a) [a ..])
and related properties.

> What does it mean to you? What makes the
> current behavior more useful than the proposed behavior?

[...]

> You say we've seen that this behavior is useful in this thread, but
> I'm not sure what it is we have seen.

More specifically, what I said is that we've seen that list range
notation is useful in some situations where a complete enumeration of
possible values is not useful, or where such an enumeration isn't the
same one we'd hope for out of a list range.  What I meant was that we've
noticed that the current behavior on Float is incompatible with being a
complete enumeration.  I'm taking it for granted that the current
behavior on Float is useful; I honestly don't see how you could argue
with that.  People use it all the time; I used it just this morning.  Of
course it's useful.

-- 
Chris