Splitting SYB from the base package in GHC 6.10
José Pedro Magalhães
jpm at cs.uu.nl
Fri Sep 5 02:37:48 EDT 2008
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Libraries