base package -- goals

Joachim Breitner mail at
Mon Feb 25 14:31:56 CET 2013


Am Samstag, den 23.02.2013, 10:27 +0000 schrieb Simon Peyton-Jones:
> I’d like to be very clear about goals, though.  I have not been
> following this thread closely enough, but is there a Wiki page that
> explains what the goals of the base-package break-up is?  

I added a Goals section to
and besides

> I believe that the driving goal is:
> ·       to allow changes to internals without forcing a version-bump
> on ‘base’, on which every package depends

added these two goals, which I find worthwhile to pursue:

To allow packages to be explictly about what they need

        A library that does not use the IO monad could communicate that
        just by not depending on some base-io package. Similar with the
        Foreign Function Interface or unsafe operations.
To allow alternative implementations/targets

        A Haskell-to-Javascript compiler will not support File IO, or
        maybe not even IO at all. It would be desirable such an
        implementation has a chance to at least provide a complete and
        API compatible base-pure package, and that one can hence
        reasonably assume that packages and libraries depending only on
        base-pure will indeed work without modification. This might be
        subsumed by fulfilling the previous goal.

Just by looking at the goals, the variant with a big base package that
uses all kinds of “uglyness” (FFI for pure stuff, cyclic dependencies
between API-wise unrelated stuff, lots of GHC internals used) and
re-exporting packages that have a more specific and possibly more stable
API sounds like it can provide the mentioned goals.

Iain commented this idea earlier this thread¹ with three points:

> * No-one would use the new packages unless they come with GHC;
>   e.g. not a perfect analogy, but compare the number of rev-deps
>   according to of the various
>   *prelude* packages vs base:
>       4831 base
>          6 basic-prelude
>          8 classy-prelude
>          4 classy-prelude-conduit
>          2 custom-prelude
>          1 general-prelude
>          1 modular-prelude
>         17 numeric-prelude
>          2 prelude-extras

Hopefully the problem here (often-changing base) is big enough and the
alternative (more purpose-oriented and more stable) packages are
attractive enough to make people use the new set.

> * If it comes with GHC, it would mean us permanently maintaining the two
>   levels

True. I’m not convinced that it will be too much a burden, at least if
the reexporting packages do that on the module level.

> * base would still be an opaque blob, with too many modules and cyclic
>   imports, which makes development tricky

Does it really make development tricky? I’d rather expect it to make
development easier, because you _can_ mix, say, IO and Foreign stuff
easily and even use some of that in lower levels. If it were less tricky
to separate it, then my experiment at would have been
less work...

In any case there is still the problem: What and where is the Prelude...
but maybe let’s postpone this.



Joachim "nomeata" Breitner
Debian Developer
  nomeata at | ICQ# 74513189 | GPG-Keyid: 4743206C
  JID: nomeata at |

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <>

More information about the Glasgow-haskell-users mailing list