base package -- goals

[Simon Peyton-Jones]

| > 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.

Yes, that's right. (A) sounds like a low-cost way of meeting some goals.  (B) is a higher-cost way of meeting some further goals.


Your follow-on remarks (appended below) about which implicit Prelude you get if you (say) import only `base-pure` are well-taken, but they apply equally to (B).  Worth adding a section to the Wiki page to discuss this?

My gut feel: for the minority who do not want to depend on enough base-X packages to get the Haskell-98 Prelude, use NoImplicitPrelude (since indeed you don't depend on enough to get the H98 Prelude) and import what you want explicitly.

Most people won't care and will continue to depend on enough to get Prelude.

Simon



| 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 at debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C
|   JID: nomeata at joachim-breitner.de | http://people.debian.org/~nomeata