base package (Was: GHC 7.8 release?)

[Ian Lynagh]

On Wed, Feb 13, 2013 at 06:28:22PM +0100, Joachim Breitner wrote:
> 
> Am Mittwoch, den 13.02.2013, 13:58 +0000 schrieb Ian Lynagh:
> > 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.
> 
> can you transparently re-export a module from another package? I.e. if
> base depends on io, IO provides System.IO, is there a way for base to
> tell ghc to pretend that System.IO is in base, but that there is no
> conflict if io happens to be un-hidden as well.

No. But there are currently no packages that depend on both base and io,
and anyone adding a dependency on io would remove the base dependency at
the same time.

> It seems that something like this would be required to move modules from
> base to something below it without breaking existing code.

I don't see why that's necessary. base would end up containing a load of
modules that look something like

    {-# LANGUAGE PackageImports #-}
    module System.IO (module X) where

    import "io" System.IO as X

> Also, if it works that smooth, this would not have to be one big
> reorganization, but could be done piece by piece.

It's tricky to do it piece by piece. It's hard to remove individual
sensible pieces in the first place, and it means that you can't
subsequently move modules between packages later without breaking code
depending on the new packages.

> > 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.
> 
> Why remove base? If it is just a list of dependencies and list of
> modules to be re-exported, then keeping it (but advocate that it should
> not be used) should not be too much a burden.

* Any package using it doesn't benefit from the reduced version bumps,
  so we do actually want packages to move away from it

* Even though base (probably) wouldn't require a lot of work at any one
  time, it would require a little work every now and again, and that
  adds up to a lot of work

* Any time a module is added to one of the new packages, either we'd
  have to spend time adding it to base too, or packages continuing to
  use base wouldn't (easily) be able to use that new module.

> (This is assuming that the reorganizing should not change existing
> module names. If your plan was to give the modules new names, this
> problem does not exist, but I’d rather prefer the less intrusive
> approach.)

The odd module might be renamed, and there will probably be a handful of
definitions that move from one module to another, but for the most part
I was envisaging that we'd end up with the same modules exporting the
same things.


Thanks
Ian