Splitting SYB from the base package in GHC 6.10

[Claus Reinke]

>I think the area of contention is pretty small.  As I understand it,
>no-one wants to change the instances you call [standard], for the types

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

This list already includes some [partial] instances - just knowing
that these types have 'Data' instances isn't sufficient to use 'Data'
operations on them safely (while avoiding runtime errors).

>So they might as well go with the Data class.  That leaves the [partial]
>instances that would have to be taken out of syb to make most of the
>other packages independent of it:
>
>Ratio Complex
>Ptr StablePtr ForeignPtr

'Ratio' has a complete 'Data' instance, it just isn't consistent;
the 'gfoldl' operation assumes a nullary constructor/no visisble
constructors (abstract type) while the 'gunfold' operation assumes
a binary constructor (concrete type, internal constructor). 'Complex'
seems to be missing an instance?

>Assuming something sensible is done for the first two, would there
>really be any need to change these?

That depends on whether the [partial] 'Data' instances can be
completed in a sensible way for these types. If they can't, then
the way forward would be to split the 'Data' class into those
operations supported by all current instances and those only
supported by the types in [standard]. That way, one would the
presence of instances would at least be indicative of the presence
of instance methods, providing more static type safety. But if the
'Data' class and some instances are in 'base', there'd be no
changing them (*).

Claus

(*) of course, it would be nice if ghc's deriving mechanism was
based on a derived instance specification in the module providing
the class, rather than being hardcoded into the compiler itself;
so even with 'Data' out of 'base', that part currently cannot be
changed without updating ghc. or if class aliases allowed the
generated old-style 'Data' instances to be re-interpreted as
'DataA' and 'DataB' instances.. but none of that is realistic for
the current split decision.