[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
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
More information about the cabal-devel
mailing list