[Haskell-cafe] RE: Packages and modules
simonpj at microsoft.com
Mon Jul 3 12:45:38 EDT 2006
Concerning packages, Alex asks:
| We covered this extensively in the Cabal vs Haskell thread starting
| 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 package P exposes a module called P.M and package Q exposes Q.M.
| P's internal modules are called P.something, and similarly for Q.
| rely on some social mechanism for allocating new package names, as
| 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
| Base.Data.List' rather than just 'import Data.List'. But nothing
| 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
| ensure their package won't conflict with others. If they choose
| 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
| keeping names unique by implicitly using package-ids is worth the
| 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
Concerning other mail on this subject, which has been v useful, I've
revised the Wiki page (substantially) to take it into account.
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 :-)
More information about the Haskell-Cafe