Concerning packages, Alex asks: | We covered this extensively in the Cabal vs Haskell thread starting | here: http://www.haskell.org//pipermail/libraries/2005-April/003607.html | | You concluded it by saying on April 22: | | And this observation points towards a simpler solution: rather than | invisibly pre-pend the package name, just get the programmer to do so. | So package P exposes a module called P.M and package Q exposes Q.M. All | P's internal modules are called P.something, and similarly for Q. (We | rely on some social mechanism for allocating new package names, as now.) | Now of course you can import P.M and Q.M in a single module. | | That would be simple. It might be pretty inconvenient to say 'import | Base.Data.List' rather than just 'import Data.List'. But nothing forces | you to do this -- and indeed we don't do it for the current 'base' | package. The point is that it's an easy way for a package author to | ensure their package won't conflict with others. If they choose not to | avail themselves of it, it's more likely that their package will be | unusable because of accidental name conflicts. | | Bottom line: the current story is pretty defensible. I'm not sure that | keeping names unique by implicitly using package-ids is worth the | bother. | | http://www.haskell.org//pipermail/libraries/2005-April/003672.html | | It seems like you are changing your position with this proposal? Any | reason for doing so? A fair question. The basic reason is that packages are now a "given". Cabal has packages, with globally unique names and versioning, and we should build on, not duplicate, this infrastructure. Once someone establishes a unique package name, that should be enough: no need to *additionally* establish unique module names, let alone for every single module in the package. Concerning other mail on this subject, which has been v useful, I've revised the Wiki page (substantially) to take it into account. http://hackage.haskell.org/trac/ghc/wiki/GhcPackages Further input (either by email or by adding material to the Wiki) would be welcome. (No guarantee Simon M agrees with what I've written... I'm at home this afternoon :-) Simon