Re-exporting namespaces (was: Re: Packages and modules)
simonmarhaskell at gmail.com
Fri Jul 7 06:20:20 EDT 2006
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
..... 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.
More information about the Libraries