base package (Was: GHC 7.8 release?)

[Wolfram Kahl]

On Thu, Feb 14, 2013 at 03:48:51PM +0100, Joachim Breitner wrote:
> 
> Yesterday, I experimented a bit with base’s code, [...]
>
> Maybe the proper is to reverse the whole approach: Leave base as it is,
> and then build re-exporting smaller packages (e.g. a base-pure) on top
> of it. The advantage is:
>       * No need to rewrite the tightly intertwined base.
>       * Libraries still have the option to have tighter dependencies.
>       * Base can evolve with lots of breaking changes, as long as they
>         do not affect the API by the smaller packages.
>       * Development of this collection can happen outside the GHC tree.
>       * Alternative implementations for (some of) these packages can be
>         created, if the reason why they could not be moved out of base
>         is one of implementation, not of API
> 
> How does that sound?

Essentially good to me...


One might consider instead (as has been proposed before, I believe),
to rename the current ``base'' to something like ``ghc-base''
which is not intended to be depended on by packages not shipped with GHC
(that is, by default ``hidden'' in ghc-pkg), and instead export:
  base   with a very stable interface
  io     with a very stable interface
  GHC    with a probably rapidly evolving interface.
  *      possibly other packages giving access to internals

Most packages that currently depend on ``base'' would then depend
only on ``base'' and possibly ``io'', and by virtue of the stability
of these two interfaces would therefore not be affected
by most GHC releases.

This would effectively be
   ``splitting the interfaces GHC and io out from base''
instead of
   ``deprecating base and replacing it with the three new interfaces
     base-pure, io, and GHC''.

That choice is possibly mostly a matter of taste ---
I think that the name ``base'' is good for a user-facing interface,
and the name ``ghc-base'' more indicative of its
implementation-dependent character.


Wolfram