Stop untracked dependencies!

[S. Alexander Jacobson]

If we are in agreement about the overall goal, then I'll move on to 
the specific issues that need addressing:

* We Need Free Packaging

Anyone should be able to create a package at any time for use in their 
projects without having having to negotiate with any particular 
centralized authority or community.

HTTP URLs have this property.  The current package namespace does not.
Malcolm says "think wiki."  I say: think world wide web.

* Free Packaging Means We To Handle Collisions in Module Namespace

Anyone should be able to use any combination of packages they want in 
any of their programs at any time without worrying about whether those 
packages export the same module name.

Simon says:
> We don't allow programs to contain two modules with the same name, for
> good reasons.

I'm not asking for that.  I am totally ok with each module name 
mapping to one and only one implementation per program.  I just want 
to be able choose that implementation even when my program uses two 
packages that both happen to export the same module name.

* We Need to Associate Module Names with Specific Packages

In associating module names with particular packages, the design 
choices come down to:

   a. using a "Modules" file that maps module names to package ids/URLs

   b. allowing package ids/URLs in import statements

   c. allowing package *names* in import statement and using an
      external "Packages" file to map package
      names to package ids/URLs.

You could extend Cabal to implement (a).  I just think (a) is really 
annoying because it forces you to edit an external packages file every 
time you do an import.

I prefer (c) because it does not have this problem and import 
statements and remains very readable while instantly communicating the 
dependency being created.

* Default Exposed Packages Are Untenable

Although, I agree that fussing with a -packages command line is 
annoying, the need to associate module names with packages ids
makes the existing default exposed package compromise untenable.

But, all is not lost!  If you choose (c) above, nothing stops you from 
having a default global "Packages" file.  Then your marginal work is 
just to supply a package name in your import statements e.g.:

   import HaXML HaXML.XML.Parse

And this doesn't seem so bad.  And, the big bonus here is that the 
default case of using Cabal gets much simpler because it can extract 
the package names from your code and then automatically include 
the relevant subset of the global packages file in your code.  No more 
need to produce a "build-depends" line manualy and no more risk of 
getting it wrong!

You get an even bigger bonus if the package format has a standard 
content-type because then Cabal can offer the packaging user the 
option of including the dependent packages in the code itself so the 
user doesn't have to worry about the recipient not having access to 
the Internet, etc.

* In Any Case, Default Exposed Packages Are Also a Poor Compromise.

I don't want to have to worry about accumulating untracked dependcies 
when I am doing quickie work with GHCi.  I want my dependencies 
checked every step of the way and should not have to round trip 
through a Cabal packaging step just to verify them.  Adding 
-fhide-all-packages without doing (c) above does not solve this 
problem.  It just means that I keep having to restart GHCi with a 
different command line every time I change a dependency OR I can keep 
GHCi open and lose track of which packages I have added interactively 
or just lose track of which packages are still necessary.  In any 
case, (c) with a default packages file is nearly as simple and MUCH 
cleaner.

* Conclusion: Freedom is good.

At the top level, the choices comes down to these tradeoffs:

   1. accepting some form of bureaucratic centralized control of
   package and module name space in exchange for the putative
   convenience of having default exposed packages and increasing the
   risk of untracked dependencies.

   -or-

   2. reduing the risk of untracked dependencies and gaining freedom
   from centralized control in exchange for acceptings some
   responsibility for specifying which packages you want to use.

I weigh the risk of untracked dependencies highly and think the 
marginal cost to the user of supplying package names in import 
statements is minimal so I strongly prefer (2) and (c).

-Alex-

______________________________________________________________
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com