On Mon, 2006-10-30 at 08:51 +0000, Simon Peyton-Jones wrote:

I think most of you know that GHC 6.6 made (IHMO) a significant step forward, by allowing a program to contain multiple modules with the same name, if they are from different packages. That means that package authors can choose module names freely, rather than worry about accidentally colliding with other packages. (We'd regard it as unacceptable if the local variables of a function could not have the same name as the local variables of another procedure!)

That still leaves an open question, not resolved by GHC 6.6: what to do if you want to import module M from two different packages into the same module? (A related question is when you have to decide what your module is called.) This can be tackled in at least three different ways, one being Frederik's proposal. Simon and I are not wedded to any particular one, and we'd welcome a consensus on what to do.

The state of play is summarised here http://hackage.haskell.org/trac/ghc/wiki/GhcPackages which includes a link to the package-mounting proposal.

If you care about this stuff, do debate it -- and please record points that survive a bit of discussion on the Wiki pages. None of this is very hard to implement; the difficulty is settling on a good design.

Fairly closely related to this issue is the question of how Cabal is supposed to deal with building packages that expect multiple versions of a dependent package. Currently this should actually work. If you specify: build-depends: foo = 1.0, foo = 2.0 Then cabal really does pass "-package foo-1.0 -package foo-2.0" to ghc. However it's less clear how we should make it work with configurations where we need to be able to add additional constraints on a package version: build-depends: foo configuration: os(windows) build-depends: foo >= 2.0 So should this mean that we get two versions of package foo? We need to be able to both in fact; add extra versions of a package and add extra version constraints to an existing package. Duncan