Re-exporting namespaces (was: Re: Packages and modules)

[Simon Marlow]

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