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