cabal design

Simon Peyton-Jones simonpj at microsoft.com
Tue Aug 16 11:31:53 EDT 2005


| First of all I want to thank Isaac Jones for his work on Cabal.
| 
| There are a few issues I would like to raise.

Seconded -- Isaac you are doing a great job.  As are lots of other
contributors.

One rather vexed question is the issue of whether a single program can
contain two modules with the same name.  Currently that is absolutely
ruled out, and as a result packages are fundamentally non-modular: every
package must use a distinct space in the global namespace. 

Simon Marlow and I have gradually become convinced that we have to fix
this, and the only sensible way to fix it is to relax the language
design so that

       a module name must be unique within its package (only)

That means that module A.B.C could exist *both* in package P1 and in P2.
And both packages could be linked into the same program.

Some kind of 'grafting' or 'mounting' scheme would be needed to bring a
package into the package namespace.  One might say
	ghc -c Foo.hs -package gtk-2.3 Graphics.GTK
to mount the gtk-2.3 package at Graphics.GTK in the name space.  Outside
the package one would need to import Graphics.GTK.M, but *within* the
package one just imports M.  That way the entire package can be mounted
elsewhere in the namespace, if desired, without needing to change or
recompile the package at all.

The exact details of the mounting scheme, and whether it is done at
build time, at install time, or at compilation time, or all of the
above, are open to debate.  We don't have a very fixed view.


However, the fundamental thing GHC needs to do is to include the package
name into the names of entities the package defines.  That means that
when compiling a module M you must say what package it is part of:
	ghc -C M.hs -package-name my-package-2.3

Then M.o will contain symbols like "my-package-2.3.M.f" etc.  In effect,
the "original name" of a function f in module M of package P is <P,M,f>.


The purpose of this message is
	a) To advertise our willingness to implement this in GHC
	b) To ask whether doing so would be welcome, and if so to invite
the Cabal
		afficionados to come up with a specific design for the 
		programmer's interface
	c) To ask what the Hugs story might be.  That is, are any of the
		Hugs folk willing to implement the necessary?

The thing about (c) is that it'd be a Big Pity if new-style packages
couldn't be used with Hugs because they don't obey the unique-module
constraint.  Ditto nhc.

Simon


More information about the Libraries mailing list