Packages and modules

[Ketil Malde]

Malcolm Wallace <Malcolm.Wallace at cs.york.ac.uk> writes:

> John Meacham <john at repetae.net> wrote:

> I tend to the opposite view.  The meaning of the code should be
> expressed in the code itself.  

Sounds like a reasonable principle.

> If a module M imports A.B.C, and I can see two such modules called
> A.B.C, then the meaning of the code is ambiguous and ill-defined.

Surely this depends on the relationship between the two A.B.C., and I think
you make the underlying assumption that they implement different things. 

But I think it's far from uncommon that they are intended to implement
the same funcitonality.  E.g I might be developing my A.B.C to be used
as a replacement for somebody else's A.B.C.  Or perhaps I just want to
check out performance with the latest development version of A.B.C.

Now, to be able to test my version without rewriting all client code,
I suppose I must download and modify the entire package containing
somebody else's A.B.C, and replace A.B.C with my version in it.

I'd much rather do this substitution from the command line; 
    ghc -hide foo -package myfoo ...

Another case that nobody seem to have mentioned, is what happens if I
move a module from one package to another.  Say somebody finds out that
'base' is getting crowded, and wants to move Data.Set to
'collections'.   Annotated imports would then have to be updated,
while ghc --make would quickly work out the unannotated imports, and
do the right thing. 

-k

PS: Talking about module A.B.C seems a bit abstract.  Perhaps the wiki
page could be updated with some examples of namespace collisions that
people have experienced?
-- 
If I haven't seen further, it is by standing in the footprints of giants