Quoth Chris Smith <cdsm...@gmail.com>, ... > As for Enum, if someone were to want a type class to represent an > enumeration of all the values of a type, then such a thing is reasonable > to want. Maybe you can even reasonably wish it were called Enum. But > it would be the *wrong* thing to use as a desugaring for list range > notation. List ranges are very unlikely to be useful or even meaningful > for most such enumerations (what is [ Red, Green .. LightPurple]?); and > conversely, as we've seen in this thread, list ranges *are* useful in > situations where they are not a suitable way of enumerating all values > of a type.
It isn't a life or death requirement, but I have dealt with enum values that are ordered and that could usefully be represented in a range. Even your example -- given a set of hues, it's sensible to order them following the spectrum, so [Cyan .. YellowGreen] might represent the hues in the set that are at all in the green range. I'm frankly using Enum as an equivalent to C "enum", symbolic integers, where the range is more or less implicit as by default the integer values are [0..]. While I (vaguely) understand that Haskell's Enum is different, the C idiom should at least testify that there's some practical value in the notion of a range of Enum, or something like it. Though not with floating point values, of course. Donn _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe