Hi Alex, On 08 April 2005 16:09, S. Alexander Jacobson wrote:
This choice adds complexity without adding value.
It adds a lot of value: it will prevent untracked dependencies from creeping into Cabal packages. That's gotta be a good thing, right? With -hide-all-packages, there are no exposed packages by defualt, which is what you were arguing for!
The simplest approach would be for -i to take precedence over default packages.
That only partly solves the problem - you can still write source code that depends on environmental settings by importing modules from exposed packages. Even so, it seems a reasonable suggestion. We thought about it, but discovered that it leads to more problems: you can allow a local module M to override a module M in a package P only as long as nothing from P is required by any module in the current program. To know that, you have to examine all the modules in the current program, which is difficult when doing separate compilation. You could end up with some modules compiled in a context that thinks M is a local module, and others compiled thinking M comes from package P. Bad things probably happen, and it's not clear that we can always tell that this has happened before delivering the executable. At the least, the error turns up at unpredictable points (eg. when you turn optimisation on).
The -hide-all-packages approach creates much higher risk of testing in a package context out of sync with the world at large.
Hmm, I don't think you've understood what -hide-all-packages does. It gives you a *consistent* view of packages across all installations: it eliminates differences between what packages are exposed by default at different sites. That is a Good Thing. You'd probably be more comfortable if -hide-all-packages was the default. Well, I'm not going to argue with that, except to say that it probably will be the default when using Cabal.
What we really need is a community consensus system (wiki or dns) for mapping module names to package locations and for implementations to interpret modules in this context.
Hackage will effectively provide a function from Module -> [Package] that's what you want, right? But we don't want a single centralised registry for module names, so it will also be possible to get packages from source other than Hackage.
Package names that are not URLs add complexity without value.
Just think of all our existing packages as having an implicit prefix of http://haskell.org/packages/ (or something). Does that help? We'll get full URLs as package names in the future (at least, that's what I'd like to see). Cheers, Simon
Simon, 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. Abstractly, we can imagine a two column table with one column containing unique module names and the other column containing package locations (perhaps available from hackage). With such a table, you eliminate untracked dependencies by hiding all modules from a package any time the programmer uses any module name from that package (you should also explicitly tell the user which packages are being hidden and why). If you are doing separate compilation, you should then be accumulating lists of package that must be hidden at link time. Is there a major problem with doing this? 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, 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. -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com On Fri, 8 Apr 2005, Simon Marlow wrote:
Hi Alex,
On 08 April 2005 16:09, S. Alexander Jacobson wrote:
This choice adds complexity without adding value.
It adds a lot of value: it will prevent untracked dependencies from creeping into Cabal packages. That's gotta be a good thing, right?
With -hide-all-packages, there are no exposed packages by defualt, which is what you were arguing for!
The simplest approach would be for -i to take precedence over default packages.
That only partly solves the problem - you can still write source code that depends on environmental settings by importing modules from exposed packages.
Even so, it seems a reasonable suggestion. We thought about it, but discovered that it leads to more problems: you can allow a local module M to override a module M in a package P only as long as nothing from P is required by any module in the current program. To know that, you have to examine all the modules in the current program, which is difficult when doing separate compilation. You could end up with some modules compiled in a context that thinks M is a local module, and others compiled thinking M comes from package P. Bad things probably happen, and it's not clear that we can always tell that this has happened before delivering the executable. At the least, the error turns up at unpredictable points (eg. when you turn optimisation on).
The -hide-all-packages approach creates much higher risk of testing in a package context out of sync with the world at large.
Hmm, I don't think you've understood what -hide-all-packages does. It gives you a *consistent* view of packages across all installations: it eliminates differences between what packages are exposed by default at different sites. That is a Good Thing.
You'd probably be more comfortable if -hide-all-packages was the default. Well, I'm not going to argue with that, except to say that it probably will be the default when using Cabal.
What we really need is a community consensus system (wiki or dns) for mapping module names to package locations and for implementations to interpret modules in this context.
Hackage will effectively provide a function from
Module -> [Package]
that's what you want, right? But we don't want a single centralised registry for module names, so it will also be possible to get packages from source other than Hackage.
Package names that are not URLs add complexity without value.
Just think of all our existing packages as having an implicit prefix of http://haskell.org/packages/ (or something). Does that help? We'll get full URLs as package names in the future (at least, that's what I'd like to see).
Cheers, Simon
(removing some CCs)
"S. Alexander Jacobson"
Simon,
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.
I disagree. The basic system will be: - the users add build-depends to their .cabal files - their software, is built (by cabal) with the -hide-all-packages, and cabal adds -package flag for each explicit dependency, so: - if there is any dependency on a package not mentioned in the .cabal file, the program will fail to build with cabal. - (Previously[1], the user could fail to mention dependencies for "exposed" packages and not get an error.) So the -hide-all-packages makes a great deal of sense and provides value. I don't think that your characterization of it is constructive. It works with the packaging system that exists today in GHC. Most of the infrastructure is outside of the compiler[2]. There are pros and cons to that, but that's the reality of every compiler I know of. peace, isaac [1] That is, currently. [2] The "packaging system" bits that include cabal, hackage, and ghc-pkg are all external to the compiler. The compiler only does the relatively small job of knowing how to find the modules when given a -package flag (or when a package is exposed).
participants (3)
-
Isaac Jones -
S. Alexander Jacobson -
Simon Marlow