irrelevant package
Simon Marlow
simonmar at microsoft.com
Wed Jun 15 09:47:54 EDT 2005
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
More information about the Libraries
mailing list