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 _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe