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