Stop untracked dependencies!

[Simon Marlow]

On 01 April 2005 20:31, S. Alexander Jacobson wrote:

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

Absolutely!  I suggested that URLs should be valid package names before,
and I still think that's a reasonable solution.

Using Hackage will be completely optional.  No-one is about to tell you
how and where you can distribute your own packages.

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

I'm afraid it's the same thing, because packages are indivisible.
Packages are indivisible for two reasons:

  - modules within a package depend on each other.  If you need one,
    you need all its dependencies too.  Packages don't tell you what
    their inter-module dependencies are.  That's part of the reason
    for having packages: to decrease the granularity of dependencies.

  - technical reasons: a package may be shipped as a shared library,
    which is indvisible and populates the global symbol table with
    all of its symbols.  You can't pick and choose which ones you
    want.  (static libraries allow a kind of shadowing, but it would
    also lead to problems I think).

So to do what you're asking for, we'd have to support overlapping
modules.  I agree with your reasoning for wanting to be able to do this:
we need as much freedom to be able to combine packages from third
parties as possible.  Unfortunately, it requires a non-trivial
technological leap.

> * We Need to Associate Module Names with Specific Packages

You could specify the connection between modules and packages if you
want.  Given that you can't use two packages containing the same module,
the information would be redundant (apart from documentation) right now.

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

Your global "Packages" file is a source of untracked dependencies, isn't
it?  Don't I have to provide that file with every scrap of source code I
publish?  How do I merge someone else's Packages file with mine?  In
what way is it better than specifying dependencies in a .cabal file
which is already shipped with a package?

Also, the Haskell module hierarchy is supposed to reflect functionality,
whereas package names are purely administrative.  This is a reason for
not including package names in source code.

There are some other administrative details which amount to
dependencies, and which are tracked by .cabal files but not by your
proposal:

  - language extensions
  - include paths
  - library paths
  - C library dependencies
  etc.

some of these you can put in {-# GHC_OPTIONS #-}, but not all.  And in
any case you probably want to specify them once per package, not once
per module.

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

Your dependencies are still untracked.  But anyway, I see the point.  If
you want package dependencies checked as you write source code, here are
a couple of possibilities:

  - GHC could have a checked pragma on each import, eg:

      import {-# PACKAGE base >= 1.0 #-} Data.List

    I don't want to write these in my source code personally,
    but it would be easy enough to implement.  It could be
    made mandatory, optionally.

  Or:

  - GHCi could have a Cabal front end.  i.e. you give GHCi a
    .cabal file instead of specifying source files directly,
    and it checks dependencies.  This is easy enough to
    implement too.

In both cases you would have to restart GHCi if you made use of a
non-exposed package, thoughl.

> * Conclusion: Freedom is good.

No argument from me on that one!

Cheers,
	Simon