Splitting SYB from the base package in GHC 6.10

[José Pedro Magalhães]

Hello,

On Thu, Sep 4, 2008 at 11:49, Ross Paterson <ross at soi.city.ac.uk> 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 <dave at zednenem.com> wrote:

> 2008/9/4 José Pedro Magalhães <jpm at cs.uu.nl>:
> > ./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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/libraries/attachments/20080905/9c92a7e3/attachment.htm