[Haskell-cafe] Packages and modules

Brian Hulley brianh at metamilk.com
Sun Jun 25 05:16:28 EDT 2006

Hi -
At the moment there is a problem in that two packages P and Q could contain 
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 are 
searched in the right order.
However suppose P and Q also contain another module with the same name, eg 
And suppose a user module wants to use Data.Foo from P but Data.Bar from 

I'm wondering: would it not be easier to just make it that the package name 
is prepended to the hierarchical module name, so the modules would instead 
be called by the names P.Data.Foo and Q.Data.Bar?

As I see it, this would have at least these advantages:

1) A package author would only have to ensure that the name of the package 
(eg Edison, FPS, Base) is globally unique, and would then be free to name 
the modules in the package without having to worry about conflicts with 
other packages

2) Users of packages could specify exactly which modules they want to use, 
which would also make it easier to switch between different implementations 
of the same data type provided by different people etc

3) When you read the program text, you could immediately see which packages 
the modules came from, so you would know which packages you need to download 
if you don't currently have that module on your system. (At the moment, if I 
come across "import Data.Foldable" I've got no idea where to get it from.)

It seems to me that the only reason this wasn't done in the first place was 
that originally there was just a flat module namespace, whereas with 
hierarchical modules it seems obvious to put the package name at the 
beginning (eg in Java the modules are called java.xyz, com.company.xyz etc 
to ensure there are no namespace conflicts)

(On the Haskell' wiki there is 
but this doesn't appear to consider the above solution.)

Regards, Brian.

Logic empowers us and Love gives us purpose.
Yet still phantoms restless for eras long past,
congealed in the present in unthought forms,
strive mightily unseen to destroy us.


More information about the Haskell-Cafe mailing list