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. Fortunately command-line linking works, because the linker links libraries lazilly. As long as we never have to use a linker that doesn't have this property, we're ok. We still have to check for real conflicts: where the package is really part of the dependencies of the program, and also shares a module name with the program. This can be checked for when compiling a module. GHCi just about copes, by virtue of linking in packages on demand. But, if you happened to require a package P and later changed the program so that it didn't need P any more but used a module name from P, you would have to restart GHCi. So, I think it's ok, just about. Cheers, Simon
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
participants (2)
-
Duncan Coutts -
Simon Marlow