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 _______________________________________________ cabal-devel mailing list cabal-devel@haskell.org http://www.haskell.org/mailman/listinfo/cabal-devel
