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 nome...@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nome...@joachim-breitner.de | http://people.debian.org/~nomeata
signature.asc
Description: This is a digitally signed message part
_______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users