Malcolm Wallace wrote:
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?
I think this is an oversimplification. Usually you want your source code to be abstract with respect to certain properties of the environment: eg. I don't care to include the path to the file containing module M in the source code, so that I can move M around if I need to. Similarly I don't want to specify the exact version of any module I depend on, since the same code probably works with a range of versions. I certainly want to specify that dependency somewhere (but only in one place, eg. foo.cabal). Cheers, Simon