Splitting SYB from the base package in GHC 6.10

[Claus Reinke]

>> I have no idea whether these would give you sufficient flexibility to
>> work on 'syb' after the ghc release
>
> I think I've missed something: What is the work that can't be done
> before the instances are moved?

If I understand José's intentions correctly, the idea is to keep the
'Data' class intact this round, but to give the 'syb' package maintainer
and users the flexibility to try and improve the situation with 'Data'
instances; ie, either

    - improve the currently partial and incomplete instances, or
    - not provide/import those instances that can't be completed

But if the existing incomplete instances are not moved out of
the way, their implicit import/export will always interfere with
whatever new instances 'syb' might try to provide. So it seems
as if we need one of:

    - ability to update 'base', changing the instances in place
    - ability to selectively import the incomplete instances, so
        that we can chose to import either the old ones or the
        new ones (or neither, if fixing turns out to be impossible)

Unless you want to keep everything as it is, that is; or have I
missed something?

Claus