base package -- goals

[Joachim Breitner]

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

-------------- 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: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20130225/81b338b6/attachment.pgp>