base library and GHC 6.12

[Simon Marlow]

On 26/06/2009 08:23, Simon Peyton-Jones wrote:
> | 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.

I fully agree that (2) is hard.  Having thought about this a bit more, 
I'm tending towards moving *no code at all* into new-base, keeping it as 
a pure re-export of bits from base-internals only.  It's much simpler:

   - we always know where the code is

   - there's no arbitrary split based on implementation details

   - we never have to move things just because the implementation
     details change

I don't think moving just some of the modules is going to make life 
easier for anyone, and it'll make life more complicated for some of us.

Cheers,
	Simon