[Haskell-cafe] Packages and modules
S. Alexander Jacobson
alex at alexjacobson.com
Tue Jun 27 00:34:53 EDT 2006
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.
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
It seems like you are changing your position with this proposal? Any
reason for doing so?
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com
On Mon, 26 Jun 2006, Simon Peyton-Jones wrote:
> Simon and I have been thinking about fixing this, and we think we might
> actually do so for GHC 6.6. Your message provoked us to write up the
> design. It's here
> Feedback welcome
> It's worth reading the old threads; for example
> But there are many others!
> | -----Original Message-----
> | From: haskell-cafe-bounces at haskell.org
> [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Brian
> | Hulley
> | Sent: 25 June 2006 10:16
> | To: Haskell-cafe
> | Subject: [Haskell-cafe] Packages and modules
> | Hi -
> | At the moment there is a problem in that two packages P and Q could
> | the same hierarchical module eg Data.Foo, and the only way for user
> code to
> | ensure the "right" Data.Foo is used is to ensure that packages P and Q
> | searched in the right order.
> | However suppose P and Q also contain another module with the same
> name, eg
> | Data.Bar.
> | And suppose a user module wants to use Data.Foo from P but Data.Bar
> | Q!!!
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
More information about the Haskell-Cafe