So I don't like this idea of re-exporting namespaces. Here's why. When I see 'import M', I have to search not only the filesystem, but also for possible namespaces re-exported by *all* the other import declarations in the file, which means I have to understand all those other import declarations, and the process is recursive. eg. in the example from the wiki: module Gtk (namespace AllOfGtk) where import namespace "gtk-2.4" Graphics.UI.Gtk as AllOfGtk module MyGUI where import Gtk import Button ..... Button.label ..... In this example, Button is in the namespace re-exported by Gtk, but the reverse might just as well be true, we have no idea when compiling MyGUI. If this is hard for the compiler, it's hard for the user too. Someone understanding your source code has a lot of places to look to find the target of an import. ----------- I believe there should be a clean separation between - constructing the global module namespace, and - interpreting the source code of a module that is, mapping an import declaration to a module should require nothing more than searching the filesystem and package database. This is true now, and I think we should ensure it remains true, for the benefit of tool and language implementors. Of course the import declarations are free to change the module namespace as it is presented to the source code: modules can be renamed, or maybe even grafted, but these declarations scope only over the source code of the module, and have no effect on other import declarations. Incedentally, this same problem crops up with qualified exports, and it is one reason I don't like qualified exports either. Cheers, Simon