Malcolm.Wallace at cs.york.ac.uk
Tue Aug 16 12:37:19 EDT 2005
"Simon Peyton-Jones" <simonpj at microsoft.com> writes:
> 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
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 <P,M,E> in nhc98,
on that fabled day when I finally implement a Cabal-style package
registration tool for nhc98, (which unfortunately won't be anytime
soon). The grafting scheme may turn out to be straightforward too,
but as I've indicated, I'm a bit less keen on it.
More information about the Libraries