Simon says:
I'm afraid it's the same thing, because packages are indivisible.
In other words, packages should be minimal sets of mutually interdependent modules. This fact combined with no-grafting rule's global module namespace implies that the whole notion of build-depends or package files is a mistake! Module names map directly to sets of project locations via some community consensus. And user visible package names are just overhead. We just need a way for a community to resolve module names to package locations. Ideally, this would be a standard protocol by which haskell implementations can do such lookups of package URLs against a set of known module name servers. Strawman protocol 1: Define a new DNS record, URL, and define some translation of module names into domain names. Strawman protocol 2: Use HTTP/HTTPS and define a query syntax such as GET ResolverURL/moduleName and use 30x headers for redirection to the appropriate server. Thoughts? -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com On Mon, 4 Apr 2005, Simon Marlow wrote:
On 01 April 2005 20:31, S. Alexander Jacobson wrote:
If we are in agreement about the overall goal, then I'll move on to the specific issues that need addressing:
* We Need Free Packaging
Anyone should be able to create a package at any time for use in their projects without having having to negotiate with any particular centralized authority or community.
Absolutely! I suggested that URLs should be valid package names before, and I still think that's a reasonable solution.
Using Hackage will be completely optional. No-one is about to tell you how and where you can distribute your own packages.
* Free Packaging Means We To Handle Collisions in Module Namespace
Anyone should be able to use any combination of packages they want in any of their programs at any time without worrying about whether those packages export the same module name.
Simon says:
We don't allow programs to contain two modules with the same name, for good reasons.
I'm not asking for that. I am totally ok with each module name mapping to one and only one implementation per program. I just want to be able choose that implementation even when my program uses two packages that both happen to export the same module name.
I'm afraid it's the same thing, because packages are indivisible. Packages are indivisible for two reasons:
- modules within a package depend on each other. If you need one, you need all its dependencies too. Packages don't tell you what their inter-module dependencies are. That's part of the reason for having packages: to decrease the granularity of dependencies.
- technical reasons: a package may be shipped as a shared library, which is indvisible and populates the global symbol table with all of its symbols. You can't pick and choose which ones you want. (static libraries allow a kind of shadowing, but it would also lead to problems I think).
So to do what you're asking for, we'd have to support overlapping modules. I agree with your reasoning for wanting to be able to do this: we need as much freedom to be able to combine packages from third parties as possible. Unfortunately, it requires a non-trivial technological leap.
* We Need to Associate Module Names with Specific Packages
You could specify the connection between modules and packages if you want. Given that you can't use two packages containing the same module, the information would be redundant (apart from documentation) right now.
* Default Exposed Packages Are Untenable
Although, I agree that fussing with a -packages command line is annoying, the need to associate module names with packages ids makes the existing default exposed package compromise untenable.
But, all is not lost! If you choose (c) above, nothing stops you from having a default global "Packages" file. Then your marginal work is just to supply a package name in your import statements e.g.:
import HaXML HaXML.XML.Parse
Your global "Packages" file is a source of untracked dependencies, isn't it? Don't I have to provide that file with every scrap of source code I publish? How do I merge someone else's Packages file with mine? In what way is it better than specifying dependencies in a .cabal file which is already shipped with a package?
Also, the Haskell module hierarchy is supposed to reflect functionality, whereas package names are purely administrative. This is a reason for not including package names in source code.
There are some other administrative details which amount to dependencies, and which are tracked by .cabal files but not by your proposal:
- language extensions - include paths - library paths - C library dependencies etc.
some of these you can put in {-# GHC_OPTIONS #-}, but not all. And in any case you probably want to specify them once per package, not once per module.
* In Any Case, Default Exposed Packages Are Also a Poor Compromise.
I don't want to have to worry about accumulating untracked dependcies when I am doing quickie work with GHCi. I want my dependencies checked every step of the way and should not have to round trip through a Cabal packaging step just to verify them.
Your dependencies are still untracked. But anyway, I see the point. If you want package dependencies checked as you write source code, here are a couple of possibilities:
- GHC could have a checked pragma on each import, eg:
import {-# PACKAGE base >= 1.0 #-} Data.List
I don't want to write these in my source code personally, but it would be easy enough to implement. It could be made mandatory, optionally.
Or:
- GHCi could have a Cabal front end. i.e. you give GHCi a .cabal file instead of specifying source files directly, and it checks dependencies. This is easy enough to implement too.
In both cases you would have to restart GHCi if you made use of a non-exposed package, thoughl.
* Conclusion: Freedom is good.
No argument from me on that one!
Cheers, Simon _______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries