On 15 June 2005 15:19, Duncan Coutts wrote:
> 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.
Right, GHC does know the real package dependencies of the program, and
it uses those for linking, but only for --make and GHCi. Ordinary batch
linking (ghc Main.o -o foo) doesn't know the dependencies, and there's
no good way for it to find out. But we currently require you to give
explicit -package flags for batch linking, so I suppose this is ok.
I called it shadowing because I think it is a kind of shadowing: when
you import a module, the compiler has to search for it, and the proposal
is that if the module is both on the local search path and in a package,
then the local module takes precedence. GHC 6.4 currently takes the
package module, and HEAD emits an error message in this case. I'm not
proposing that you should be able to replace, say, Network.Socket with
your own local version and yet still use the network package - that
would definitely lead to problems, and the compiler should check for
that.
The problem with all this is that GHC internally has a function of type
isHomeModule :: DynFlags -> Module -> Bool
where DynFlags contains the package database. This becomes harder to
implement if a package module can be a local module under certain
circumstances... hmm, this isn't as easy as I thought.
Cheers,
Simon
