On Mon, Sep 15, 2008 at 13:28, José Pedro Magalhães
<jpm@cs.uu.nl> wrote:
- Ratio has to be fixed to have a consistent instance: either
it's seen as an abstract datatype (therefore with undefined gunfold) or
a gfoldl has to be defined matching its gunfold;
Ratio had its gfoldl defined to match its gunfold. Since GHC.Ratio exports the constructor (:%), I guess Ratio cannot be considered abstract.
- Complex should have its derived instance restored (or otherwise a manual instance with a proper gfoldl);
Complex had its derived instance restored.
- Other places that have to be changed:
- The Data instance of Data.Array should be moved from Data.Generics.Instances into Array, to avoid syb dependency;
This was not done, since I am unsure if it would break some sort of Hugs compatibility. If the instance for Array is in Data.Data (note that it is not an orphan anymore), then it's provided independently of where the Array comes from. If it would be in Data.Array, then Hugs would have to provide an instance in its Array library too.
- The imports of SYB in the following modules should be fixed to avoid bringing into scope all the instances:
./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
This was not done, given the discussion in [1] regarding instance visibility and orphans.
The following "dubious" instances are now in the syb package (in the Data.Generics.Instances module): DataType TyCon TypeRep Handle ThreadId StablePtr (a -> b) (IO a) (ST s a) (STM a) (IORef a) (TVar a) (MVar a). All the other instances are in the base package, Data.Data module.
Ian, do you think this could be incorporated in any possible upcoming beta versions/release candidates before the final release? I did some sanity checking but it would be good if a wider audience could test it.