"Simon Peyton-Jones"
One rather vexed question is the issue of whether a single program can contain two modules with the same name. ... the fundamental thing GHC needs to do is to include the package name into the names of entities the package defines.
I agree that, ultimately, the compiled name of an entity must be the triple ( package, module, entity name ) to enable packages to be truly modular.
Some kind of 'grafting' or 'mounting' scheme would be needed to bring a package into the package namespace.
I disagree that this necessarily mandates a grafting or mounting scheme. Whilst it might be useful, even desirable, it is a separate question. For instance: package P contains a module A package Q contains a module A package R depends on package P There is no dependency of package Q on P or R. A user wishes to use both R and Q in her program U. No problem. There is only one module called A visible to U, namely that contained in Q, and grafting is not required. What if she wants to use packages P and Q? Again no problem, provided she does not import A at all. By analogy with the lazy resolution of imported entities that is already a feature of Haskell'98, there is no conflict, and no resolution mechanism is needed. So what if she wants to use packages P and Q, /and/ to import a module A in program U? Well, let us split program U into two sub-programs U1 and U2. U1 imports A, and is compiled against only the single package required to provide A (either P or Q). U2 does not import A, but can safely import U1, and be compiled against both P and Q. OK, so this manual process is slightly tedious, and maybe upsets the current model for ghc --make (which I think currently adds all packages in the dependency graph to the namespace for all modules?). But it shows that the more minimal extension is feasible and does not outlaw any combination of packages. I do also worry a little that grafting could introduce worse namespace problems that we haven't thought of, simply because we haven't had a chance to play with it yet.
The thing about (c) is that it'd be a Big Pity if new-style packages couldn't be used with Hugs because they don't obey the unique-module constraint. Ditto nhc.
I'd be willing to to implement naming triples