[Haskell] RE: package mounting

Duncan Coutts duncan.coutts at worc.ox.ac.uk
Mon Oct 30 06:25:16 EST 2006

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

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.


More information about the cabal-devel mailing list