Splitting SYB from the base package in GHC 6.10

[Simon Peyton-Jones]

| Instead of repeating myself in full, I'd prefer you'd refer to my previous
| emails (ask if they were unclear), but here is the gist of it (with no claim
| of completeness):

Claus, I found your summary very helpful.  Thank you!  Although you may have said it all before, I find it very difficult to keep a whole email thread in my head, and I find compact summaries really helpful.

| 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

Ross's comments (reproduced below) look sensible to me.  In the short term we probably don't know enough to be sure of doing the Permanently Right Thing.  But time is short for 6.10, so I think for that near-term goal we should concentrate on something modest.

My criterion is:

base:   stuff that (a) we don't expect to want to change
        and (b) that others might want to build on in a different way

syb:    stuff that may change

There is a tension between (a) and (b); and the base/syb boundary may well be fuzzy.

Concretely, I propose that we follow more or less Ross's suggestion:

base:  the Data class itself and [standard] instances,
        and any [partial] instances that we feel confident won't change

syb:    leftover [partial] instances, and [misfits]
        plus lots of SYB library code

My reading of Claus's message is that, modulo discussion of some details of [partial], he'd go with that plan.

I urge *against* making a new package for Data/Typeable, for now at least.  The gain is slight or absent, and there is a cost in terms of new package dependencies, and the possibility that we may later decide to cut the cake another way.  We recently decided to un-do the proposed splitting out of packages for 'getopt', 'st', 'concurrent', 'timeout' etc. for this very reason.  See http://www.haskell.org/pipermail/libraries/2008-August/010543.html

Is that acceptable to others?  If so, someone (Jose) needs to sort out the details.  19 Sept is GHC's release candidate, so we need this done well before then.

Simon

| -----Original Message-----
| From: libraries-bounces at haskell.org [mailto:libraries-bounces at haskell.org] On Behalf Of Ross Paterson
| Sent: 03 September 2008 09:14
| To: libraries at haskell.org
| Cc: José Pedro Magalhães
| Subject: Re: Splitting SYB from the base package in GHC 6.10
|
| On Wed, Sep 03, 2008 at 12:29:09AM +0100, Claus Reinke wrote:
| > 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.
|
| 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
|
| 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
|
| Assuming something sensible is done for the first two, would there really
| be any need to change these?