base package -- goals
simonpj at microsoft.com
Mon Feb 25 15:25:03 CET 2013
| I added a Goals section to
Thanks. But the first goal, which is the dominant one, is very unclear to me as my comments mentioned. A description of what the problem is, and why a simple "API wrapper" approach would not solve it, would be useful.
| -----Original Message-----
| From: glasgow-haskell-users-bounces at haskell.org [mailto:glasgow-haskell-
| users-bounces at haskell.org] On Behalf Of Joachim Breitner
| Sent: 25 February 2013 13:32
| To: glasgow-haskell-users at haskell.org
| Subject: Re: base package -- goals
| 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
| 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
| > 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
| https://github.com/nomeata/packages-base/tree/base-split 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.
| ¹ http://www.haskell.org/pipermail/glasgow-haskell-users/2013-
| Joachim "nomeata" Breitner
| Debian Developer
| nomeata at debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
| JID: nomeata at joachim-breitner.de | http://people.debian.org/~nomeata
More information about the Glasgow-haskell-users