| > Moreover, I think Simon does too. He proposes that we should lift the | > overlap restriction by having module names map to (cabal-package, | > module) pairs. | | Well, the overlap restriction exists in the language already. | If you want to lift it, you really need to change the language. | Simon's proposal (which I support) is a hack to permit the restriction | to be lifted without changing existing code, by re-interpreting all | module imports to have an implicit (disambiguating) prefix. It is | just an engineering tradeoff to ensure that huge mounds of legacy code | are not broken purely for the sake of some rather rare overlap case. My motivation is actually this. In a function definition, the caller of the function need not care what the function's local variables are called. But in a Haskell program, the importer of a module M *does* need to care about the names of modules that are imported by M (i.e. are part of M's internal implementation). He needs to care because he can't use those module names. Indeed two modules M and N might simply be unusable in the same program, merely because the implementers of M and N happened to choose the same name for an internal sub-module. I think that's undesirable. The "solution" I was advocating arranges that a *package* must use unique module names, but two packages need not care about the modules used inside each other. But this solution only works smoothly for internal modules. What if packages P and Q both expose a module called M? Then you can't import M-from-P and M-from-Q into the same importing module, because the importing module has no way to say which M he means. And this observation points towards a simpler solution: rather than invisibly pre-pend the package name, just get the programmer to do so. So package P exposes a module called P.M and package Q exposes Q.M. All P's internal modules are called P.something, and similarly for Q. (We rely on some social mechanism for allocating new package names, as now.) Now of course you can import P.M and Q.M in a single module. That would be simple. It might be pretty inconvenient to say 'import Base.Data.List' rather than just 'import Data.List'. But nothing forces you to do this -- and indeed we don't do it for the current 'base' package. The point is that it's an easy way for a package author to ensure their package won't conflict with others. If they choose not to avail themselves of it, it's more likely that their package will be unusable because of accidental name conflicts. Bottom line: the current story is pretty defensible. I'm not sure that keeping names unique by implicitly using package-ids is worth the bother. Simon