| 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@haskell.org [mailto:glasgow-haskell- | users-bounces@haskell.org] On Behalf Of Joachim Breitner | Sent: 25 February 2013 13:32 | To: glasgow-haskell-users@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@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C | JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata