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