Packages and modules

[Malcolm Wallace]

Simon Marlow <simonmarhaskell at gmail.com> wrote:

> > 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