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

[S. Alexander Jacobson]

Short summary of my big point from my prior mail

   We want late binding of module names to implementations.
   Effectively, module names should be treated as URLS.

Argument
1. We want loose coupling of packages/modules.
2. "Build-depends" tightly couples packages/modules
3. Binding of module names to implementations should be at run time
    not package time

See here
http://www.manageability.org/blog/stuff/recombinant-long-tail/view
http://www.markbaker.ca/2002/09/Blog/2003/10/03#2003-09-mnot-late-binding

There is a natural connection between late binding of module names and 
REST architectural style.

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

On Mon, 11 Apr 2005, Simon Marlow wrote:

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