base package -- goals

[Joachim Breitner]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://www.haskell.org/pipermail/glasgow-haskell-users/attachments/20130312/f51aefef/attachment.pgp>