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.