Hi, Am Montag, den 11.03.2013, 23:45 +0000 schrieb Simon Peyton-Jones:
| I don’t feel in the position to actually make a call here, or even to cast a vote with | confidence, but I’m happy to continue summarizing the discussion until a | consensus is found. If there is more discussion, that is.
I've updated the page http://hackage.haskell.org/trac/ghc/wiki/SplitBase a bit.
thanks.
It seems to me that there are two kinds of goals
A Better for external clients (stable APRs, few version bumps) B Better for internal implementation (eg using containers or bytestring in base)
On the Wiki page, (G1) and (G2) are to do with group (A). And this seems best handled by defining client-facing shim packages that export just what you want.
However (G4) and later seem to be concerned with (B), and they clearly do require re-structuring the code.
It seems entirely possible to me that BOTH will be needed. That is, the structure to achieve (B) will not be precisely what is wanted for (A). So it seems to be me that both approaches are valid and we might want to do both. We can do them in either order, or simultaneously. (Mind you, doing (A) first would make (B) less disruptive for our users.)
In short, less of an either/or, more of a both/and.
from reading between the lines I get the impression that you’d prefer (A) to happen first, in order to do (B) more easily. If (A) was successful, we even have to worry less about bad decisions while doing (B), as it would be relatively easy to fix these. So if we do (A), we still have the problem that Ian pointed out: Why should anyone use these shim packages, when they can continue to use base? This is especially true when the shim packages are less simple to use, due to the handling of Prelude. I see some options (assuming, just for demonstration, we have to shim packages base-pure and base-io): 1. Prelude stays in base, packages wanting to use the shim packages exclusively have to use {-# LANGUAGE NoImplicitPrelude #-} everywhere and import stuff explicitly. base-pure would probably provide its subset of the Prelude in Prelude.Pure, to be imported explicitly. 2. Prelude goes to a separate shim package, base-prelude. Extra dependency required, packages that want to only depend on base-pure have no Prelude to use, same problem as in 1. 3. Every shim package has a Prelude module. Good for those who depend on base-pure, but those who require both base-pure and base-io have no an ambiguous import. 4. Separate packages base-io-prelude and base-pure-prelude providing Prelude’s containing stuff of base-* (+ dependencies). Packages can pull in precisely the Prelude they want, but yet more packages. None of these look particularly appealing. Here some ideas to make it more convenient for the programmer that require changes to GHC and how it treats packages: I. It automatically imports _all_ visible Prelude modules. So base-pure provides the pure Prelude and base-io adds the IO functions. II. Same, but a bit more explicit: We extend the package configuration by a "prelude-modules" field. Every module listed in that field of every visible package is treated as a Prelude and automatically imported (unless {-# LANGUAGE NoImplicitPreldue #-} is active.) III. Ambiguous module imports do not cause an error if, among the modules, there is one that is a superset of all others, i.e. reexports all other modules. I personally find I. quite elegant and appealing, as it is clearly the behavior expected by library authors if they have their code build-depend on their selection of shim packages, and requires no extra prelude packages. One might see it as a disadvantages that now arbitrary packages can add to the “virtual prelude”, although I don’t think it would be abused without good reason, and who knows what clever things people will do with that feature. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata@debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata@joachim-breitner.de | http://people.debian.org/~nomeata