On Thu, Sep 4, 2008 at 11:49, Ross Paterson
<ross@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@zednenem.com> wrote:
2008/9/4 José Pedro Magalhães <jpm@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.