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

S. Alexander Jacobson alex at alexjacobson.com
Mon Apr 11 13:58:05 EDT 2005


Simon,

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.

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!

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.

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

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

Does this make sense?

-Alex-

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


On Sun, 10 Apr 2005, Simon Marlow wrote:

> On 08 April 2005 22:24, S. Alexander Jacobson wrote:
>
>> The -hide-all-packages option would make sense only if there were real
>> flexibility in selecting which packages to use in implementing the
>> modules imported into your program.  However, in our discussions, you
>> you've defined two rules that eliminate this flexibility:
>>
>> * you cannot use two different modules with the same module ID in the
>>    same program
>>
>> * you cannot use two different packages with the same module ID in the
>>    same program
>>
>> Together these constraints imply that packages should contain only
>> minimal sets of mutually interdependent modules; every additional
>> module included in a package restricts its usability.  So, if no two
>> packages should contain the same module name, one must therefore
>> conclude:
>>
>>   Package Dependency Rule: The module names used in a program
>>   completely specify the packages required to interpret/compile it.
>
> No, that doesn't follow.  You can most certainly have lots of packages
> with the same module, you just can't use them in the same program.
>
> How do you think we plan to have multiple versions of packages?
>
> [ stuff about the -i overriding problem deleted... I'll think about it
> and post to a new thread.]
>
>> To be clear, my problem with -hide-all-packages is that it creates
>> much greater risk of getting out of sync with the global table.
>> Build-depends tags are actively bad because you cannot know the nth
>> degree dependencies of the packages you are using.  Correctness is
>> only with respect to the global table.
>
> Yes, the user has to know about dependencies because of the overlap
> restriction.  But dependencies are completely visible: you *can* know
> the dependencies of the packages you're using.
>
> I'm not sure what you mean by "global table".
>
> One day we'll lift the overlap restriction and things will get easier,
> but not right now (unless you have a patch!).
>
>> Yes, I am begging the question of how we construct and manage global
>> tables in a way that preserves free-packaging/decentralization.
>> (Perhaps it is with user specifiable hackage tables)  But, there is
>> no point in talking about solutions until we agree on the problems
>> that need to be solved.
>
> At this point I'm a bit hazy on what problem you still think needs to be
> solved :-)
>
> We've eliminated untracked dependencies from Cabal packages.  At some
> point, we'll generalise package names to URLs (assuming community
> agreement and a concrete proposal).  Hackage will be providing a
> centralised package repository for those that want it.
>
> Cheers,
> 	Simon
>



More information about the Libraries mailing list