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