"S. Alexander Jacobson"
* 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.
Agree. And this is the default current case.
HTTP URLs have this property. The current package namespace does not. Malcolm says "think wiki." I say: think world wide web.
Wiki might have been a poor example, but I did also mention DNS as a model for package naming. URLs are *not* completely arbitrary. You first require a valid domain name, which gets allocated by a single (but distributed) authority, using a lax first-come-first-served policy (at least approximately). And then you can only create a valid URL if you have permission from the domain owner to write to the webserver. You want all package authors to distribute their works through individual webservers, where they have their own self-appointed authority. I don't have a problem with that, but I would also like to have one or more trusted webservers, which collect together many packages, making them all available easily, with search facilities, and some reasonable dependency/update policy. The "trusted" authority would be, broadly speaking, the (or /a/) community, which would probably strive for a certain coherency and even perhaps "style" across packages. Think of the difference between building a Linux system by collecting the latest versions of every system tool and application yourself from the individual project websites, resolving all cross dependencies manually, or just downloading a complete RedHat, debian, SuSe, whatever, distribution, where somebody has already done the dependency analysis for you. Debian is a particularly good example, since you might collect only a minimal system to start with, but be secure in the knowledge that when you want to add more packages, they will be compatible, and the community has resolved all of the dependencies for you transparently. Some people will want to do the former. More power to them. But the vast majority will prefer the latter, simply for convenience.
* Free Packaging Means We To Handle Collisions in Module Namespace
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.
Yes, clashes of module names is absolutely the most central issue in the whole library universe. In the beginning, the Haskell module namespace was flat - big opportunity for overlaps - bad. Then we introduced hierarchy - a much larger namespace, more easily searchable - but still the potential for overlaps. So then we introduced "packages" - to gather modules together, so that we could permit the same hierarchical module name in different packages, provided the package name was different. Originally, we said that package names must be unique, but now you want package names to overlap as well. So now, to avoid ambiguity, the proposal is that the *storage location* of the package should be unique. It seems to me that we are just pushing the overlap-resolution problem around the plate - each time a new namespace is introduced, the potential for overlaps rears its ugly head again, and yet another new mechanism is proposed, which eventually fails to solve the problem too. You are against a central authority for allocating package names, yet you seem happy to accept a central authority for allocating the domain name part of a URL. So I conclude that you are not against central authority itself, but rather you would prefer to use a "standard" well-established authority (the DNS) rather than a new, yet-to-be-implemented authority (Hackage). Would that be a fair guess?
* We Need to Associate Module Names with Specific Packages
In associating module names with particular packages, the design choices come down to:
a. using a "Modules" file that maps module names to package ids/URLs
b. allowing package ids/URLs in import statements
c. allowing package *names* in import statement and using an external "Packages" file to map package names to package ids/URLs.
There is another choice: d. Have one or more external servers resolve module names to specific packages. Requires a single file specifying a list of servers to contact, in preference order. If a server cannot resolve the name, it is delegated further down the list. For a project that uses lots of wild packages with odd version numbers and weird dependencies, you might need to set up your own dedicated server just for that project. But most projects would just use two servers: (a) a local one for locally-written packages, and (b) a central community one for publically-contributed packages. Regards, Malcolm