Simon Marlow
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 agree with all that. The mapping of the package name to its location in the filespace should not be in the source code. That is the job of a package management tool.
I certainly want to specify that dependency somewhere (but only in one place, eg. foo.cabal).
The question for me is whether the .cabal file therefore counts as source code. Certainly the .cabal file no more specifies where packages are located in the filesystem than do any of the proposals on the table. But if the .cabal file is needed in order to disambiguate the code, what happens if someone wants to use a Makefile instead of Cabal? You can see where this leads - any number of build systems could potentially have an influence on the meaning of the code. So I think one good thing about the current proposals is that they move the package dependencies into the source code itself, where they cannot get lost or forgotten or overlooked. The *dependency* is noted, but the details of how to locate a package are rightly left to tools. But the biggest problem is really your phrase "(but only in one place)". I agree that specifying the dependencies close together is good in principle. But occasionally, you need to have different package dependencies for different modules of a single project - this is a finer granularity of dependency than Cabal is currently good at expressing. Regards, Malcolm