Splitting SYB from the base package in GHC 6.10

Ross Paterson ross at soi.city.ac.uk
Thu Sep 4 05:49:26 EDT 2008


On Thu, Sep 04, 2008 at 09:44:34AM +0200, José Pedro Magalhães wrote:
> Complex has a derived instance. In Data.Complex:
> 
>     data (RealFloat a) => Complex a
>       = !a :+ !a   
>     # if __GLASGOW_HASKELL__
>             deriving (Eq, Show, Read, Data)
>     # else
>             deriving (Eq, Show, Read)
>     # endif
> 
> Was there a problem with this?

I was looking at the HEAD, where the instance was moved into
Data.Generics.Instances, and used the default definition of gfoldl.
Presumably if the Data class is in base, there's no problem with
restoring the derived instance.

> Regarding the other places that have to be changed [1]:
> 
>     ./array/Data/Array.hs
> 
> The Data instance of Array should be moved from Data.Generics.Instances
> into Array, to avoid syb dependency.

The instance needs only the Data class, so it would be independent of syb.
Its proper place is the array package, but since GHC defines Array in
GHC.Arr it might define the instance there too.

>     ./containers/Data/IntMap.hs
>     ./containers/Data/IntSet.hs
>     ./containers/Data/Map.hs
>     ./containers/Data/Sequence.hs
>     ./containers/Data/Set.hs
>     ./containers/Data/Tree.hs
>     ./network/Network/URI.hs
>     ./packedstring/Data/PackedString.hs
> 
> As far as I can see, these are not problematic, but the imports should
> be fixed to avoid bringing into scope all the instances.

These packages should be able to avoid depending on syb.

>     ./haskell-src/Language/Haskell/Syntax.hs
>     ./template-haskell/Language/Haskell/TH/Quote.hs
>     ./template-haskell/Language/Haskell/TH/Syntax.hs
> 
> The use of Ratio instances here is not problematic if the instance
> for Ratio is fixed?
> 
>     ./bytestring/Data/ByteString/Internal.hs
>     ./bytestring/Data/ByteString/Lazy/Internal.hs

I assume so.

> These depend on an instance for ForeignPtr Word8. What to do here?
> Reclassify instances for types with phantom types into "standard",
> since there is nothing to traverse?

That was the suggestion.  The types in question are Ptr, ForeignPtr
and StablePtr.  (I think the Var's are similar, but it's not essential
to decide about them now.)


More information about the Libraries mailing list