Re: Splitting SYB from the base package in GHC 6.10

Hello, On Thu, Sep 4, 2008 at 11:49, Ross Paterson wrote:

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.

Oh, I didn't know this had changed. I was looking in 6.8.3. Then yes, it should probably return to where it was. On Thu, Sep 4, 2008 at 18:25, David Menendez wrote:

2008/9/4 José Pedro Magalhães :

...

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

I see some partial instances. For example, Data.Set throws exceptions for toConstr and gunfold.

Yes, but those are defined instances, not imported instances. I believe that is not this problem (it is a problem, just not the one we're focusing on right now). Those would have to wait for a possible "break up" of the Data class, as Claus suggested. Thanks, Pedro