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