Somebody claiming to be Roman Cheplyaka wrote:

* Simon Marlow [2013-02-13 09:00:15+0000]

...

It's feasible to split base, but to a first approximation what you end up with is base renamed to ghc-base, and then the new base contains just stub modules that re-export stuff from ghc-base.

It would be great to have a portable base, without any GHC-specific stuff in it. After all, modules like Control.Monad or Data.Foldable are pure Haskell2010.

+1 -- Stephen Paul Weber, @singpolyma See http://singpolyma.net for how I prefer to be contacted edition right joseph

I would like to see base split up, but I am reluctant to invest the effort to do it. I'm not going to do it myself, and Ian's time is so precious on many fronts. My guess is that it'll need someone else to take the lead, with advice from HQ. Simon | -----Original Message----- | From: ghc-devs-bounces@haskell.org [mailto:ghc-devs-bounces@haskell.org] On | Behalf Of Ian Lynagh | Sent: 13 February 2013 13:58 | To: Simon Marlow | Cc: wren ng thornton; glasgow-haskell-users; ghc-devs@haskell.org | Subject: Re: GHC 7.8 release? | | On Wed, Feb 13, 2013 at 09:00:15AM +0000, Simon Marlow wrote: | > | > I believe Ian has done some experiments with splitting base further, | > so he might have more to add here. | | There are some sensible chunks that can be pulled out, e.g. Foreign.* | can be pulled out into a separate package fairly easily IIRC. | | Part of the problem is that it's hard to see what's possible without | actually doing it, because base is so large, and has so many imports and | import loops. IMO by far the easiest way to improve base would be to | start off by breaking it up into lots of small packages (some of which | will probably be single-module packages, others may contain an entire | hierarchy like Foreign.*, and others may contain an odd mixture of | modules due to dependency problems). | | Then we can look at which packages ought to be split up, which ought to | be coalesced, and which ought to be moved higher up or lower down the | dependency tree, and then look at which module imports are preventing | what we want to do and see if there's a way to fix them (either by | moving a definition and reversing an import, or by changing an import to | import something lower down the dependency tree instead). | | If we go this route, then we would probably want to end up without a | package called 'base', and then to make a new package called 'base' that | just re-exports modules from all the new packages. I imagine the first | release would let people use the new base without warnings, a year later | new base would give deprecated warnings, and the following year we'd | remove it. We could do this process slower, but the sooner packages move | off of base, the sooner they benefit from fewer major version bumps. | | The advantages would be: | * the new packages would be easier to maintain than base is | * we could more easily make other improvements we'd like to make, e.g. | we could move the unix and Win32 packages further down the tree | without having to do it in one big leap, and without having to put | them below the whole of base | * if one module causes a major version bump, then only libraries using | that functionality would need to relax their dependencies, rather than | every single package | * some targets (JS, JVM, .NET, etc) or other implementations might want | to do things like IO, concurrency, etc, completely differently. This | way they'd just use a different io/concurrency package, rather than | having to have a different implementation of parts of base | * it would be nice if pure libraries could simply not depend on the io | package etc, and thus clearly do no IO | | The disadvantage is that, at some point between the first release and | the release that removes base, each package will have to have its | dependencies updated. | | | Thanks | Ian | | | _______________________________________________ | ghc-devs mailing list | ghc-devs@haskell.org | http://www.haskell.org/mailman/listinfo/ghc-devs