[Haskell-cafe] Packages and modules

Brian Hulley brianh at metamilk.com
Sun Jun 25 19:44:56 EDT 2006

Robert Dockins wrote:
> On Sunday 25 June 2006 05:16 am, Brian Hulley wrote:
>> [snip]
>> 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?
> [snip discussion of this idea]
> The idea of improving the module system has been discussed a number
> of times before.  Here is a thread started by a suggestion from the
> simons which generated a fair bit of discussion:
> http://www.haskell.org/pipermail/libraries/2003-August/001310.html
> I'm not sure whatever became of this idea; discussion seemed to sort
> of reach a consensus, and then nothing happened.

Thanks for the link...

At the risk of being a "devil's advocate" I think the above idea is too 
flexible and overly complicated. Imho it would be like trying to have a 
conversation with a group of people where each person is constantly jumping 
about, changing their name and appearance, and might be replicated in 
several places at once... :-)

I'd have thought all that's needed is a nice simple "cathedralish" design 
where each module knows its globally unique place and just stays there 
forever so that it's easy to develop and share code which uses it. (Could 
Java be seen as a proof of concept here? )

Package aliases in the code would then make it easy to upgrade to the latest 
package eg

     package Graphics.Rendering.OpenGL-8-9 as OpenGL
     import OpenGL/GL.Bitmaps

In a sense the package alias idea is a little bit like grafting, except the 
aliasing is specified in the source code instead of somewhere else. Perhaps 
package aliases could even be inherited from "parent" modules...

> The module "grafting" mechanism always seemed kind of nice to me.  I
> think some of the problems discussed in this thread could be by using
> cabal, especially to specify the graftings expected for compilation.

You'd then have to keep the Cabal info in sync with the source. At the 
moment I can just use ghc --make and don't need to know about Cabal at all 
unless I want to distribute a package (or install one).

> It seems like grafting can give a plausible story for dealing with
> dynamicly loaded code, which is a nice bonus.

I hadn't thought of dynamically loaded code though...

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