Packages and modules
simonmarhaskell at gmail.com
Thu Jul 6 11:37:45 EDT 2006
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).
More information about the Libraries