GHC 7.8 release?

[Simon Marlow]

On 13/02/13 07:06, wren ng thornton wrote:
> On 2/12/13 3:37 AM, Simon Marlow wrote:
>> One reason for the major version bumps is that base is a big
>> conglomeration of modules, ranging from those that hardly ever change
>> (Prelude) to those that change frequently (GHC.*). For example, the new
>> IO manager that is about to get merged in will force a major bump of
>> base, because it changes GHC.Event.  The unicode support in the IO
>> library was similar: although it only added to the external APIs that
>> most people use, it also changed stuff inside GHC.* that we expose for a
>> few clients.
>>
>> The solution to this would be to split up base further, but of course
>> doing that is itself a major upheaval.  However, having done that, it
>> might be more feasible to have non-API-breaking releases.
>
> While it will lead to much wailing and gnashing of teeth in the short
> term, if it's feasible to break GHC.* off into its own package, then I
> think we should. The vast majority of base seems quite stable or else is
> rolling along at a reasonable pace. And yet, every time a new GHC comes
> out, there's a new wave of fiddling the knobs on cabal files because
> nothing really changed. On the other hand, GHC.* moves rather quickly.
> Nevertheless, GHC.* is nice to have around, so we don't want to just
> hide that churning. The impedance mismatch here suggests that they
> really should be separate packages. I wonder whether GHC.* should be
> moved in with ghc-prim, or whether they should remain separate...
>
> But again, this depends on how feasible it would be to actually split
> the packages apart. Is it feasible?

So I think we'd need to add another package, call it ghc-base perhaps. 
The reason is that ghc-prim sits below the integer package 
(integer-simple or integer-gmp).

It's feasible to split base, but to a first approximation what you end 
up with is base renamed to ghc-base, and then the new base contains just 
stub modules that re-export stuff from ghc-base.  In fact, maybe you 
want to do it exactly like this for simplicity - all the code goes in 
ghc-base.  There would be some impact on compilation time, as we'd have 
twice as many interfaces to read.

I believe Ian has done some experiments with splitting base further, so 
he might have more to add here.

Cheers,
	Simon