Splitting SYB from the base package in GHC 6.10
ross at soi.city.ac.uk
Mon Sep 1 10:43:00 EDT 2008
On Mon, Sep 01, 2008 at 02:49:01PM +0200, José Pedro Magalhães wrote:
> Then it was also suggested that Data.Generics.Instances  could stay in base
> (perhaps inside Basics as well). This, however, would prevent dealing with the
> "dubious" Data instances , 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
More information about the Libraries