irrelevant package

[Duncan Coutts]

On Wed, 2005-06-15 at 14:47 +0100, Simon Marlow wrote:
> On 15 June 2005 13:49, Duncan Coutts wrote:
> 
> > I think the bug in this case is the fact that the modules are
> > considered to be part your program even though they are never
> > imported (directly or indirectly) or even any modules from the same
> > package are imported (if we take the reasonable assumption that if
> > one module from a package becomes part of your program's module
> > namespace then all of them do). 
> 
> I agree, and I've been putting some serious thought into whether we can
> relax this restriction, and allow local modules to shadow package
> modules.

I'm not sure that allowing local modules to shadow package modules is
really necessary in this case.

There is the simpler (but very important) case where the local module
doesn't shadow any package module - at least not a package that is used
in the current program. So 'all' that needs to be done is to track which
packages are actually used in a program (perhaps this is harder than I
imagine). So if we never import any module from package Foo which
depends on util-1.0 then util's modules are not brought into the module
name space.

GHC obviously does this correctly when linking, that is figure out which
packages are used by the program, otherwise every program produced by
ghc --make would be linked against absolutely every library used by
every exposed package. So we just need to do the same thing when
compiling and note that the module name space does not include modules
from packages which are not imported. So an exposed packages modules
(and therefore all of the modules in dependent packages) are not
considerd to be part of the program's module namespace unless one or
more of them is actually imported.

So in the example the Gentoo packaging folk came up with of having a
dummy.cabal package file that contains no modules (ie it contains no
code and no libs) but is exposed and depends on util-1.0, then it should
never be possible for this package to be considered to be used by the
program since it exposes no modules and therefore none of its modules
can be imported. In that case the fact that this dummy module would if
it were used explicitly "-package dummy" bring all the util-1.0 modules
into the program module namespace is now not a problem because it should
never implicitly get imported because that should become imposiible.

This would only solve the problem of totally unrelated programs failing
to compile because of over-eager package imports. The problem of
actually using a library that depends on a library that uses flat module
names is obviously much harder, because in that case there genuinely is
a module name clash.

Duncan