base package -- goals
mail at joachim-breitner.de
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
> 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
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 http://packdeps.haskellers.com/reverse 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
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
https://github.com/nomeata/packages-base/tree/base-split would have been
In any case there is still the problem: What and where is the Prelude...
but maybe let’s postpone this.
Joachim "nomeata" Breitner
nomeata at debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
JID: nomeata at joachim-breitner.de | http://people.debian.org/~nomeata
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: This is a digitally signed message part
More information about the Glasgow-haskell-users