The base library and GHC 6.10
Simon Marlow
marlowsd at gmail.com
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.
Cheers,
Simon
More information about the Libraries
mailing list