Cabal vs Haskell [sic]

[Simon Peyton-Jones]

| > 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