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.)