You forgot "confusing"?
I didn't forget it
Sorry, I should have written "omitted".
perhaps we ought to ask what the cause of the confusion is.
tr.v. e·nu·mer·at·ed, e·nu·mer·at·ing, e·nu·mer·ates 1. To count off or name one by one; list: A spokesperson enumerated the strikers' demands. 2. To determine the number of; count. Regardless of how easily the children you teach get it, to me enumerating is a different thing from repeatedly adding one.
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. [..] It seems to me particularly pointless to define an Enum instance that focuses on, above all else, the inaccuracy of that approximation.
Yes. But we need an Enum instance to get the syntactic sugar of [1..10], so one is defined anyway.
Perhaps I was understating the case in saying the behavior was established but undocumented; rather, it's explicitly documented in the Haskell Report.
Absolutely, it is, as I've said, the reality - like it or not.
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.
I must admit I don't understand this comment. If the fixpoint library wants to provide the functionality (producing all values between two points), and can't/shouldn't use Enum, surely it must provide a different function, and let go of the list sugar? -k -- If I haven't seen further, it is by standing in the footprints of giants