John Meacham
Package names should never appear in source files IMHO. if a package name is in the source file, then you might as well make it part of the module name. Packages exist for 'meta-organization' of code. A way to deal with mapping code _outside_ of the language itself, putting packages inside the code will force the creation of yet another level, meta-packages, or something. packages should not be a language issue, they are an environment one.
I tend to the opposite view. The meaning of the code should be expressed in the code itself. 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. I would rather not have to look elsewhere (in the build system? Makefile? scons? Cabal file? DOS batch file? where?) to find out how to resolve the ambiguity. Surely the programmer knew which import was intended. Is it so difficult to communicate that information somewhere close to the import itself? This is the same situation as with compiler flags for language extensions, foreign imports, and so on. If a module uses a non-standard language feature that changes the interpretation of the syntax (e.g. template haskell), it should say so in the module itself {-# OPTIONS_GHC -fth #-}, so that I as a human reader know what is going on. Likewise, if a foreign import requires a C header file, that should also be referred to in the FFI decl, not solely as a build option at some arbitrary distance in the filesystem. Regards, Malcolm