base package (Was: GHC 7.8 release?)

[Joachim Breitner]

Hi,

I have started a wikipage with the list of all modules from base, for a
first round of shuffling, grouping and brainstorming:

http://hackage.haskell.org/trac/ghc/wiki/SplitBase


Am Mittwoch, den 13.02.2013, 18:09 +0000 schrieb 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.

hmm, that reminds me of how haskell98 was handled, and it was slightly
annoying when haskell98 and base eventually were made to conflict, and
we had to patch some unmaintained packages.

Ok, in this case io would be introduced with the intention of being used
exclusive from base. So as long as we make sure that the set of modules
exported by base is always the union of all modules provided by package
that have any module in common with base this would be fine.

(Why this condition? Imagine io adding IO.GreatModule without base also
providing the module. Then a program that still uses base cannot use
IO.GreatModule without fixing the dependencies _now_ (or using package
imports everywhere). It would be nice if library authors allowed to do
the change whenever convenient.)

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

Agreed.

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

We want them to do so. We should not force them (most surely will...)

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

Hopefully it is just updating the set of modules to be exported, sounds
like it could be automated, given a list of packages.

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

Hence we should add them; shouldn’t be too much work.


After every larger change to base I am forced to touch old, hardly
maintained code that I do not know, to get the packages working in
Debian again. Hence my plea for staying compatible as long as feasible.

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/20130213/6c14a94c/attachment-0001.pgp>