deriving Enum vs. deriving Bounded

[Hal Daume III]

I would guess because it's somewhat difficult to implement 'enumFrom' (and
others) for binary constructor datatypes.  Of course, it's possible, but
difficult to get enumFrom to agree with enumFromTo.  For instance, a
reasonable definition of enumFrom for (Int,Int) might enumerate
diagonally:

  enumFrom (1,1) ==>
    [(1,1), (2,1), (1,2), (3,1), (2,2), (1,3), ...]

However, for enumFromTo, such a thing would be impossible to implement if
the ranges didn't form a square (/cube/hypercube/...).  For instance, we
could rationalize

  enumFromTo (1,1) (2,3) ==>
    [(1,1),(1,2),(1,3),(2,1),(2,2),(2,3)]

or

    [(1,1),(2,1),(1,2),(2,2),(1,3),(2,3)]

but neither of these corresponds to how it would be enumerated with the
simple 'enumFrom'.

Ord is possible on all of these because we can use lexicographic ordering,
which doesn't work very well for enumerations since enumFrom in
lexicographic ordering will just fill out one column and never stop.

At least that's my intuition...

--
Hal Daume III

 "Computer science is no more about computers    | hdaume@isi.edu
  than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume

On Mon, 16 Sep 2002, Johannes Waldmann wrote:

> What is the rationale for not allowing `deriving Enum'
> for data types with a single unary constructor;
> while `deriving Bounded' is allowed in this case.
> 
> Oh I see, deriving Bounded is allowed even for a single k-ary constructor,
> but the Report probably didn't want to fix 
> an order of enumeration for the argument tuples.
> 
> But then, why is `deriving Ord' allowed in this case :-)
> as it also refers to the fixed order of arguments.
> 
> I don't intend to change anything here, I just want to understand 
> the decision made in the Report. I'm sure this issue (and many others) 
> must have been discussed - are the arguments archived somewhere?
> 
> Best regards,
> -- 
> -- Johannes Waldmann ---- http://www.informatik.uni-leipzig.de/~joe/ --
> -- joe@informatik.uni-leipzig.de -- phone/fax (+49) 341 9732 204/207 --
> _______________________________________________
> Haskell mailing list
> Haskell@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell
>