Hierarchical module namespace extension not sufficiently
sebastian.sylvan at gmail.com
Mon Jan 23 13:54:44 EST 2006
On 1/23/06, Duncan Coutts <duncan.coutts at worc.ox.ac.uk> wrote:
> To the Haskell' committee,
> I think the hierarchical module namespace extension has been generally
> 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
> I originally brought it up:
> It was discussed more a few months later:
> and the discussion moved to the libraries list:
There seems to be a suggestion already which would solve this:
qualified module GTK.Button as Button
In the export list.
More information about the Haskell-prime