base package -- goals

[Simon Peyton-Jones]

| I added a Goals section to
| http://hackage.haskell.org/trac/ghc/wiki/SplitBase

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.

SImon


| -----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
| 
| Hi,
| 
| 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
| http://hackage.haskell.org/trac/ghc/wiki/SplitBase
| 
| 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 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
| >   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.
| 
| Greetings,
| Joachim
| 
| ¹ http://www.haskell.org/pipermail/glasgow-haskell-users/2013-
| February/023774.html
| 
| 
| --
| 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