Packages and modules

[Simon Marlow]

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