base library and GHC 6.12

[Simon Peyton-Jones]

| There has been some discussion recently about the base library. In
| particular, base is supposed to follow the PvP, which means that certain
| sorts of changes require increasing the version number. When the version
| number is increased, this makes work for lots of people, as any packages
| correctly using an upper bound on base's version number need to be
| updated.


Just to add to Ian's message, I see two goals for the proposed split of the base package into two, say 'new-base' and 'ghc-base'.  (Although 'new-base' will certainly be called 'base'; but it's easier to refer to it that way in this message.)
	
1. Stable interfaces

   new-base will expose a relatively stable API.  So its version
   number will change relatively slowly, and packages that depend on
   it will continue to work wihtout change. (They will still need to
   be recompiled, but their package dependencies will be unchanged.)
  
   ghc-base exposes a much larger, and much less stable API.  Some
   other packages need acces to these internals, and are prepared to
   change more frequently as ghc-base changes.

2. Shared code

   There is quite a bit of code in 'base' that is independent of any
   particular compiler.  But it's all mixed up with GHC-specific or
   Hugs-specific code, with CPP-ery to keep them apart.  It'd b cool
   if new-base was compiler independent, with all the
   compiler-dependent piecse in 'ghc-base'.


Now, some observations:
 
  (a) Goal (1) is the Most Important Goal by far.  It is the main reason
    we are proposing to split up the base package in the first place.
    Goal (2) is nice, but I don't think anyone has really been
    seriously inconvenienced by the mixed up code in current 'base'.

  (b) Goal (1) could be achieved by leaving ALL the code in ghc-base,
    and making new-base into a package that simply imports goop from
    ghc-base, and re-exports the stable API that new-base exposes.
    That would fully achieve (1) and not achieve (2) at all.

  (c) Achieving (2) is jolly hard.  Fully achieving it is probably
    impossible. And it's fragile: there are big recursive loops -- I
    think one involves IOException, and just one dependency can
    completely screw up a proposed separation.  I think we could waste
    a lot of effort into trying to tease the two apart with little
    gain.

So I argue that we should focus on (1), and pick up as much of (2) as
convenient.  Concretely I propose:

   - That we split into two as proposed

   - That the baseline starting point is (b) above: everything in
     ghc-base.  (Which suggests that is not a good name for the
     package.)

   - That we move as much stuff *as convenient* from ghc-base to
     new-base.  Ian's message suggests that quite a lot can actually
     move, but *the details of what lives where does not matter much*.

   - That we de-emphasise the idea that the compiler-independent stuff
     goes in new-base and comiler-dependent stuff goes in ghc-base (or
     hugs-base).  If it makes sense otherwise, it's fine for there to
     be compiler-specific stuff in new-base, and unavoidable (perhaps
     dragged in by transitive dependencies) to have
     compiler-independent stuff in ghc-base.

All this is pretty much as Ian suggests.  I'm just wanting to make sure
we have the emphasis right.  

Simon