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