On Fri, 9 Jul 1999, Fergus Henderson wrote:
> > > And for other constructor kind, like say, Pair, List ...
> > > "deriving" does not seem to make much sense.
> > > Because there exist too many equally good ways to `enum' these
> > > types. Hence, it is better to leave this for the possible separate
> > > user Enum declaration.
> >
> > Ah, but the same is true for Ord and yet Ord instances may be derived
> > automatically. Deriving should do something that is clearly sensible;
> > it doesn't have to be the only thing possible. I think the
> > lexicographic ordering is clearly sensible.
>
> Can you give some (hopefully compelling) examples of why it would be
> useful to have Enum instances for such types?
If you use an array with pairs an indices to model a matrix you could very
well want to Enumerate all the indices.
data Day = Mon | ... | Sun
data Time = AM | PM
type Index = (Day,Time)
-- or newtype Index = Index (Day,Time) deriving Enum
-- or data Index = Index Day Time deriving Enum
it is reasonable to expect
[(Mon,AM)..]
to mean
[(Mon,AM),(Mon,PM),(Tue,AM),.........,(Sun,PM)]
I think that for all Bounded types, enumerations for tuples is nothing
strange. I imagine the major reason for omission from Haskell 98 is that
derived instances are annoying to implement in the compilers, and that
there is a hope for a better mechanism for deriving (an improved verison
of PolyP or DrIFT perhaps) to make it into Haskell 2.
Thus enumeration is reasonable for product types.
For sums-of-products, enumeration can also be useful:
data Maybe a = Nothing | Just a
[Nothing..] :: [Maybe Time]
should be
[Nothing,Just AM,Just PM]
So enumeration definitely works for sum-of-product types when the used
types are bounded, and the same definition can be used even if the used
types are not bounded. (But then you get an infinite list that never
visits some elements. [(0,0),(0,1),(0,2),(0,3)......])
Patrik Jansson
