The base library and GHC 6.10

Simon Marlow marlowsd at
Wed Sep 3 04:17:16 EDT 2008

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.


More information about the Libraries mailing list