Hierarchical module namespace extension not sufficiently flexible

[Duncan Coutts]

To the Haskell' committee,

I think the hierarchical module namespace extension has been generally
successful.

One of the aims was to enable people to use names like Set.union rather
than everyone having to prefix the module name onto the function name
like setUnion. 

The one area where this doesn't quite work is in large packages that
consist of many many modules. Examples include Gtk2Hs and HOpenGL. The
problem with these packages is that they do use modules; they do not
consist of a flat name space. They use the same names in different
modules. This wouldn't be too much a problem except that these large
packages consist of many modules. In the case of Gtk2Hs it has more that
100 modules. So it is impractical to import each module separately.

Basically what I want is an extension which allows me to write:

> import Graphics.UI.Gtk
and then use
> ... Button.label ...

At the moment this is not possible and we have to export buttonLabel
from Graphics.UI.Gtk. This is exactly what we wanted to avoid by using
hierarchical module names.

So I'm not suggesting any particular concrete extension (though people
have suggested various things, see below). I'd be happy with anything
that would allow me to write the above code.

So that's it. That's what we want to do for large practical libs. It
seems reasonable. Every other modern language can do it (see eg the Gtk+
bindings for C++,Java,Python,Ruby,Ocaml,etc).

This issue has been discussed before and people have made various
suggestions:

I originally brought it up:
http://www.haskell.org/pipermail/haskell/2004-December/015085.html

It was discussed more a few months later:
http://www.haskell.org/pipermail/haskell/2005-March/015462.html

and the discussion moved to the libraries list:
http://www.haskell.org/pipermail/libraries/2005-March/thread.html

Duncan