[Haskell] RE: package mounting

[Benjamin Franksen]

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