GHC 7.8 release?

[Ian Lynagh]

On Wed, Feb 13, 2013 at 09:00:15AM +0000, Simon Marlow wrote:
> 
> I believe Ian has done some experiments with splitting base further,
> so he might have more to add here.

There are some sensible chunks that can be pulled out, e.g. Foreign.*
can be pulled out into a separate package fairly easily IIRC.

Part of the problem is that it's hard to see what's possible without
actually doing it, because base is so large, and has so many imports and
import loops. IMO by far the easiest way to improve base would be to
start off by breaking it up into lots of small packages (some of which
will probably be single-module packages, others may contain an entire
hierarchy like Foreign.*, and others may contain an odd mixture of
modules due to dependency problems).

Then we can look at which packages ought to be split up, which ought to
be coalesced, and which ought to be moved higher up or lower down the
dependency tree, and then look at which module imports are preventing
what we want to do and see if there's a way to fix them (either by
moving a definition and reversing an import, or by changing an import to
import something lower down the dependency tree instead).

If we go this route, then we would probably want to end up without a
package called 'base', and then to make a new package called 'base' that
just re-exports modules from all the new packages. I imagine the first
release would let people use the new base without warnings, a year later
new base would give deprecated warnings, and the following year we'd
remove it. We could do this process slower, but the sooner packages move
off of base, the sooner they benefit from fewer major version bumps.

The advantages would be:
* the new packages would be easier to maintain than base is
* we could more easily make other improvements we'd like to make, e.g.
  we could move the unix and Win32 packages further down the tree
  without having to do it in one big leap, and without having to put
  them below the whole of base
* if one module causes a major version bump, then only libraries using
  that functionality would need to relax their dependencies, rather than
  every single package
* some targets (JS, JVM, .NET, etc) or other implementations might want
  to do things like IO, concurrency, etc, completely differently. This
  way they'd just use a different io/concurrency package, rather than
  having to have a different implementation of parts of base
* it would be nice if pure libraries could simply not depend on the io
  package etc, and thus clearly do no IO

The disadvantage is that, at some point between the first release and
the release that removes base, each package will have to have its
dependencies updated.


Thanks
Ian