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