Module Holism (was RE: exposed packages and cabal depends)

[Simon Marlow]

On 11 April 2005 18:58, S. Alexander Jacobson wrote:

> You said that no two modules in a program can share the same name.
> 
> At the same time, we want a library system that allows us to use any
> combination of modules in any program.
> 
> The problem is, we don't want to import two modules, only to
> discover that somewhere in their dependencies they each use the
> same module name to refer to conflicting module implementations.

This is the problem that the overlap restriction leads to, yes.  It is
mitigated by the fact that the granularity of dependencies is made
coarser by the packaging system, so we believe it will rarely be a
problem in practice.

Remember, when you're importing library modules, your dependencies are
on *packages*, not modules.

> Therefore, we really want to say that no two modules we might want to
> import into our programs (either directly or indirectly) should share
> the same name.  And, in particular, we don't want a packaging or
> versioning system that encourages it!

No, you've drawn a bogus conclusion again.  We most definitely want the
ability to choose between multiple instances of a particular module in
programs.  For example, if I have two versions of a package installed,
say P-1 and P-2, I want to be able to compile my old code that depends
on P-1 while still being able to write new code against P-2.  And I want
to be able to use other packages that still depend, for the time being,
on P-1.  When P-3 comes out, I don't want to be forced to uninstall P-1
and P-2 before I can use it.

This restriction on module overlaps is mainly for engineering reasons,
as I've explained before.  Someday it might be lifted, and we want the
design of the system to extend gracefully when that happens, which the
current design will.

> Build-depends assumes it is useful to talk about dependencies with
> respect to a given package, when in fact, all modules have to share
> the same namespace.  -hide-all-packages assumes it is useful to talk
> about dependencies with respect to a given system when, in practice,
> all users should be in as similar a namespace as possible.  In effect
> -hide-all-packages encourages untracked dependencies on some very
> local namespace.

Sorry, I don't understand that paragraph at all.

> What we want is a common system for mapping module names to
> module implementations.
> 
> * a protocol for resolving module-names to implementations at
>   various haskell module name servers (hackage?)

Go ahead, invent a protocol!

> * support for addition and overrides by specific communities
> (proxies?) 
> 
> * support for creation of new versions by individuals (-i override?)
> 
> And we need to constraint the versioning system to require that
> every new version of a module must fulfill the contracts of the
> prior versions so no existing dependency is broken by any changes.

That's way too restrictive.  We'd never be able to remove anything.

Furthermore, for GHC, you can't actually upgrade a library in place.
Libraries that were built against the previous version will break,
because in GHC the "contract" between compiled modules is extremely
intimate (in includes a lot more than the exported interface of the
modules).

When we start using shared libraries, even binaries will break if you
upgrade shared libraries in place.  That's why we must have versioning,
and the ability to have multiple versions of a package installed.

Cheers,
	Simon