Splitting SYB from the base package in GHC 6.10

[Ross Paterson]

On Mon, Sep 01, 2008 at 02:49:01PM +0200, José Pedro Magalhães wrote:
> Then it was also suggested that Data.Generics.Instances [3] could stay in base
> (perhaps inside Basics as well). This, however, would prevent dealing with the
> "dubious" Data instances [4], and this was one of the motivating factors to
> split SYB from base. This refers concretely to the instances:
> 
>     instance (Data a, Data b) => Data (a -> b)
>     instance Typeable a => Data (IO a)
>     instance Typeable a => Data (Ptr a)
>     instance Typeable a => Data (StablePtr a)
>     instance Typeable a => Data (IORef a)
>     instance Typeable a => Data (ForeignPtr a)
>     instance (Typeable s, Typeable a) => Data (ST s a)
>     instance Typeable a => Data (TVar a)
>     instance Typeable a => Data (MVar a)
>     instance Typeable a => Data (STM a)
>     instance (Data a, Integral a) => Data (Ratio a)
> 
> These instances are defined in such a way that they do not traverse the
> datatype. In fact, there is no other possible implementation, and this
> implementation at least allows for datatypes which contain both "regular" and
> "dubious" elements to still have their "regular" elements traversed.
> However, this implies that a user cannot redefine such instances even in the
> case where s/he knows extra information about these types that would allow for
> a more useful instance definition, for instance.

These two statements appear to be contradictory.  Perhaps an example of
a possible instance would help.

In any case, it seems there's no objection to placing the following
instances together with the Data class:

  () Bool Char Double Float Handle Ordering
  Int Int8 Int16 Int32 Int64 Integer Word Word8 Word16 Word32 Word64
  DataType TyCon TypeRep
  [] Maybe Either tuples

Claus also mentioned the Ptr/Var types, which also don't seem to have a
value that can be traversed.

I think the Ratio instance really ought to be in base, as Rational is in
the Prelude.  What about Complex?

Claus argued that -> and the monads could be treated by analogy with
Show for these types.

There is an additional problem with types like ThreadId, Array, ST, STM,
TVar and MVar: they're notionally defined in other packages, even though
they're actually defined in partially-hidden GHC.* modules in base and
re-exported.