package mounting

[Benjamin Franksen]

Simon Peyton-Jones wrote:
> [narrowing to libraries]

Um, yes, sorry.

> | > 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.
> 
> Why would authors go to great lengths to avoid overlapping module names?
> The only possible penalty of overlap is that it's a bit awkward to
> import modules with the same name into the same module.  But that's
> always fixable by making a two-line impedance-matching module.
> 
> I feel I'm missing your point.

The point is about causing maintenance headaches in the long run, see below.

> | > 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?
> 
> Yes, certainly.  Suppose that package 'foo' and 'bar' both contain
> module M.  Then you want to import foo.M into module X, and bar.M into
> module Y.  Easy: just compile X with '-package foo' and Y with '-package
> bar'.  

Ok, that seems easy enough. Especially if you only have one or just a few
such conflicts. However, suppose people take your advice (see above) and
start writing lots of libraries with module names that are no longer
carefully chosen to have a high probability of being globally unique, in
turn causing more and more such name clashes for users of these libraries.

I think it is quite clear that individually resolving such clashes for each
module where such a clash happens will scale poorly to larger projects. In
contrast, resolving the name clash once and for all (that is, per package)
by chosing an appropriate 'mount point' for each imported package (if the
default one isn't apropriate) will scale nicely and require a minimum of
maintenance.

[Besides, there is currently no way to specify module specific options when
using cabal, right? The manual says "Options required only by one module
may be specified by placing an OPTIONS_GHC pragma in the source file
affected". Which means currently one has to use, more or less, plan C or
else avoid using cabal. You have probably guessed that plan C is the one I
favour least ;-]

Cheers,
Ben