Re: Packages and modules

Malcolm Wallace writes:

John Meacham 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