[Haskell] Hierarchical module namespace extension not sufficiently flexible

Duncan Coutts duncan.coutts at worc.ox.ac.uk
Sun Mar 6 07:21:01 EST 2005

On Sat, 2005-03-05 at 22:15 +0100, Sebastian Sylvan wrote:
> On Sat, 05 Mar 2005 17:03:38 +0000, Duncan Coutts > module Graphics.UI.Gtk (
> >   qualified module Graphics.UI.Gtk.Button as Button,
> >   ...
> I like this idea a lot!

Great. We "just" have to persuade other people around here of the same,
in particular compiler implementors and the authors of the Hierarchical
Modules Addenda.

> It wouldn't break existing stuff (would it?), and it really seems like
> it should already be in there. I mean if you can import and export
> modules, it doesn't make sense that qualified imports are allowed but
> not qualified exports.

I think the reason it was not added before is down to the fact that
modules don't really export other modules. They just export other
modules contents. (Also it was a deliberately conservative extension.)

Exporting qualified names doesn't really change that, we're just
exporting the contents of a module but with qualified names.

> This strategy also allows the library author some control over the
> library's structure. I might be missing something but this really does
> look "nice".

You mean it would allow a 'virtual' structure to be exported that does
not match the actual internal structure of the library? I suppose that's

I think this is probably a bonus (so long as library authors use it

For example in Gtk2Hs, in actual fact we do not have
we have
That is we have an additional "category" layer. Otherwise we would have
all 130 modules directly in the Graphics/UI/Gtk/ directory which we
would find much harder to manage.

So it would be nice to keep this structure but to export a 'virtual'
module structure that does not mention the category.


module Graphics.UI.Gtk (
  qualified module Graphics.UI.Gtk.Windows.AboutDialog as AboutDialog
) where

import Graphics.UI.Gtk.Windows.AboutDialog


More information about the Haskell mailing list