Ketil Malde
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.
No, I agree that they may be essentially the same module, but one of them has a bugfix, or a new API call, or something.
Now, to be able to test my version without rewriting all client code, I'd much rather do this substitution from the command line; ghc -hide foo -package myfoo ...
With the Simons' proposal, and with Brian's, you would need to edit the source code at all usage positions of "import A.B.C". I agree that this is tedious and undesirable. With my proposal, you could organise your source code such that only a single file might need to be edited, replacing say module Foo (namespace F) where import namespace "foo" as F with module Foo (namespace F) where import namespace "myfoo" as F
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,
Again, I believe my proposal would permit a single update, whilst the other proposals would require multiple updates. http://hackage.haskell.org/trac/ghc/wiki/GhcPackagesWithGrafting
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?
One thing I would very much like to be able to write is regression testing over libraries. Does the computation P using package HaXml-1.15 give the same result as running P with package HaXml-1.13? At the moment, one cannot write such a test directly in Haskell, one must escape to a separate test harness. Regards, Malcolm