Packages and modules

[Simon Peyton-Jones]

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