Cabal vs Haskell [sic]

Simon Marlow simonmar at
Sat Apr 23 18:27:15 EDT 2005

On 23 April 2005 00:21, ross at wrote:

> On Fri, Apr 22, 2005 at 11:28:21PM +0100, Simon Peyton-Jones wrote:
>> 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. 
> This would obscure the hierarchy a bit.  A common current practice is
> a variant of this: modules either have allocated names or their names
> have the form
> 	allocated prefix + proper name + whatever you like
> e.g. Graphics.Rendering.OpenGL.GL.Texturing.Queries -- it seems to
> work pretty well, and should scale, as long as the proper names are
> distinct, e.g. package names or otherwise allocated.

Right.  Also, prepending package names to module names to avoid the
overlap restriction suffers from another difficulty: versioning.  You
can't combine two versions of a package without including the version
number in the module names of all the modules in the package.  But then
you end up with source code that has to be edited when the version of a
package changes, which is highly undesirable.

IMO, it's a good thing that package names and versions are separate from
module names.  It means we can (mostly) stick to the original aim of
using the module hierarchy to reflect functionality, and not clutter it
up with version numbers and other administravia.


More information about the Libraries mailing list