On 6/21/12 1:15 PM, Brandon Allbery wrote:

On Thu, Jun 21, 2012 at 5:11 AM, Rouan van Dalenwrote:

...

Can anyone shed some light on why the succ and pred functions of the Enum typeclass throw exceptions if we go over the upper or lower boundary, and not return Maybe a?

Enum and Bounded have a complicated and arguably incorrect[1] relationship. The whole thing should be overhauled,

Indeed. In light of the exception-throwing specification, it's not trivial to define a safe enumFromDownTo function satisfying the specification: enumFromDownTo x y == reverse (enumFromTo y x) with all the properties we'd like to have (e.g., list fusion). Essentially, we need access to whatever predicate decides to throw an error in the pred function, in order to use it to return the empty list when appropriate. The predicate can be reconstructed from Ord or from Bounded and Eq but both of those constructions make non-trivial assumptions about how the classes interact. Hence, the Enum class in incomplete, in addition to any correctness problems interacting with other classes. -- Live well, ~wren

On Thu, Jun 21, 2012 at 5:36 PM, Richard O'Keefe wrote: It always struck me as odd that Enum doesn't extend Ord.

There's a reason given for not having Bounded extend Ord, which doesn't really apply to a class having fromEnum :: a -> Int. Testing whether an enum bound is at a limit is thus a bit tricky.

An ordering does not typically induce a computable enumeration. For example, there are infinitely many rationals between any pair of rationals.

I hit reply instead of reply all. Sorry Richard. On Fri, Jun 22, 2012 at 4:35 PM, wrote:

...

An ordering does not typically induce a computable enumeration. For example, there are infinitely many rationals between any pair of rationals.

I didn't say it was odd that Ords weren't Enums, I said that it's odd that Enums aren't Ords.

You said: "It always struck me as odd that Enum doesn't extend Ord." Ambiguous, at best. In any case, the order induced by the enumeration of the rationals is not compatible with the magnitude/sign order either. This is typically true.

It makes little or no sense to make treat rationals as Enums; the intent of enums is generally to provide *exhaustive* enumeration of a *discrete* set.

I don't see that in the documentation anywhere, and "enumerable" is synonymous with countable/computable (depending on the context). The usual topology on the structure has nothing to do with its enumerability. The set of pairs of positive integers is "discrete" under the obvious product topology. Indeed, the "standard" enumeration is (almost) formally equivalent to that of the positive rationals. The only difference is we aren't skipping over the diagonal. Enumerating the rationals is straight-forward. http://www.cs.ox.ac.uk/jeremy.gibbons/publications/rationals.pdf