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. HTTP URLs have this property. The current package namespace does not. Malcolm says "think wiki." I say: think world wide web. * 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. * 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. You could extend Cabal to implement (a). I just think (a) is really annoying because it forces you to edit an external packages file every time you do an import. I prefer (c) because it does not have this problem and import statements and remains very readable while instantly communicating the dependency being created. * 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 And this doesn't seem so bad. And, the big bonus here is that the default case of using Cabal gets much simpler because it can extract the package names from your code and then automatically include the relevant subset of the global packages file in your code. No more need to produce a "build-depends" line manualy and no more risk of getting it wrong! You get an even bigger bonus if the package format has a standard content-type because then Cabal can offer the packaging user the option of including the dependent packages in the code itself so the user doesn't have to worry about the recipient not having access to the Internet, etc. * 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. Adding -fhide-all-packages without doing (c) above does not solve this problem. It just means that I keep having to restart GHCi with a different command line every time I change a dependency OR I can keep GHCi open and lose track of which packages I have added interactively or just lose track of which packages are still necessary. In any case, (c) with a default packages file is nearly as simple and MUCH cleaner. * Conclusion: Freedom is good. At the top level, the choices comes down to these tradeoffs: 1. accepting some form of bureaucratic centralized control of package and module name space in exchange for the putative convenience of having default exposed packages and increasing the risk of untracked dependencies. -or- 2. reduing the risk of untracked dependencies and gaining freedom from centralized control in exchange for acceptings some responsibility for specifying which packages you want to use. I weigh the risk of untracked dependencies highly and think the marginal cost to the user of supplying package names in import statements is minimal so I strongly prefer (2) and (c). -Alex- ______________________________________________________________ S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com