Claus Reinke wrote:
Leaving Data.Generics.Basics in base while moving Data.Generics.Instances to syb raises the interesting issue of dealing with the accidental re-exports of Data.Generics.Instances from various places. Here is that list again (*):
$ find . -name '*hs' | grep -v _darcs | xargs grep -l 'Data.Generics' | grep -v Generics ./array/Data/Array.hs ./base/Data/Typeable.hs ./bytestring/Data/ByteString/Internal.hs ./bytestring/Data/ByteString/Lazy/Internal.hs ./bytestring/Data/ByteString/Unsafe.hs ./containers/Data/IntMap.hs ./containers/Data/IntSet.hs ./containers/Data/Map.hs ./containers/Data/Sequence.hs ./containers/Data/Set.hs ./containers/Data/Tree.hs ./haskell-src/Language/Haskell/Syntax.hs ./network/Network/URI.hs ./packedstring/Data/PackedString.hs ./template-haskell/Language/Haskell/TH/Quote.hs ./template-haskell/Language/Haskell/TH/Syntax.hs
This raises the more general issue of instance-visibility. Since instances are automatically re-exported and therefore break abstraction barriers, the only sensible way to think about instances is as global properties. Attempting to limt the visibility of instances by putting them in separate packages or modules is futile. If an instance exists in a library *anywhere*, it potentially exists *everywhere*, and we should think of it as global. The only way to limit the visibility of instances is to not put them in a package. That means, for the particular case of the Data class, someone should decide once and for all whether there is an instance for IO, or functions, or whatever, and either define them along with the Data class or not at all. Cheers, Simon