deriving instances for "hidden" types

[Wolfgang Jeltsch]

On Friday, 2002-07-26, 18:28, CEST, Hal Daume III wrote:
> I've often felt a tinge of disappointment not being able to derive
> classes over data structures that are defined in the libraries
> (DeepSeq FiniteMap, for instance).  I was wondering if any of the
> tools (drift, etc.) or GHCs built-in meta programming would allow you
> to say something like:
> 
> derive (DeepSeq a, DeepSeq b) => DeepSeq (FiniteMap a b)
> 
> where the compiler or something "knows" the representation of
> FiniteMap even if we don't.

I think being able to do so wouldn't be good because this could lead to
improper instantiations and to dependence on the implementation. For
instance, in the CVS repository accessible via cvs.haskell.org, the Set
type is defined by
    newtype Set a = MkSet (FiniteMap a ()).
If Set a wouldn't be an instance of Eq, your deriving mechanism could be
used to produce a correct instantiation. But if sets are represented by
lists, equal sets could be represented by unequal list. In this case,
deriving the Eq instance would be fatal. So the two implementations
would lead two different instantiations where one would be correct and
the other wouldn't.

> I don't know if something like this would be possible, but if so, I'd
> find it very useful.
> 
> On the same note, if NFData/DeepSeq instances could be provided for
> all the library types, I'd really appreciate it (FiniteMap, Array,
> etc...).

I wonder if instantiating NFData/DeepSeq for types, whose implementation
is not fully exported, is a good thing. Maybe, instances of
NFData/DeepSeq could be used to distinguish between implementations
which are otherwise not distinguishable. I'm not sure if this is
desirable or not. (Well, today already seq can be used this way but
maybe this is also not so good.)

> [trailer]

Wolfgang