Simon Peyton-Jones wrote:
| > http://hackage.haskell.org/trac/ghc/wiki/PackageMounting | | It looks nice, but don't you think the -package-base flag ought to | take both the package name *and* the mountpoint? | | Otherwise, this looks like what I've wanted all along, if only I knew it ;-).
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.
I think this is true only in a very technical sense. I fear that in practice, library authors will go to great lengths to avoid such overlapping module names, because introducing them will cause too much difficulties for library users. The only way to make halfway sure that this doesn't happen is to use (fixed) module hierarchy prefixes containing (more or less) the package name, as in "Text.ParserCombinators.Parsec", even though technically they aren't forced to do so.
(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!)
Yes, but this analogy seems to cover only the problem with internal (package-local, non-exposed) modules. To widen your analogy, we'd regard it as similarly unacceptable if we had to qualify each exported entity with the module name each time we use them, even if we are inside the module that defines them, wouldn't we? Which is today's situation on the package/module level: We have to completely qualify module names with their mount point in the module hierarchy, even when refering to them from inside the package that defines them. I see, however, one point with Frederik's proposal that isn't clear to me: Assume library A uses library B. Then, presumably, lib A must chose a mount point for its use of lib B. Now imagine a program P wants to use lib A as well as directly import some module from lib B. Is P now free to give lib B its own mount point, independent of the one that was chosen by lib A? I think this should definitely be possible. There may, however, be some issues regarding implementation: Can a compilation system share code between both 'versions' of lib B (I assume they are /not/ really different versions but exactly the same one, only referred to via a different 'mount point')? Hmm, maybe this isn't really a problem. The compiler could simply alias the module names, similar as to what it does for 'import M as N'.
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?
What if I want to import them into /different/ modules (which are nevertheless part of the same package)? Can this be easily accomplished with ghc-6.6? Cheers Ben