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.
True. But I don't see how it is much different from ordinary imports: if an entity e is used in the source text, but not defined there, you must search the modules that are imported to see where e was defined. In general, e might not be explicitly defined in /any/ of the directly-imported modules, so you must recursively check their imports/re-exports.
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 think it is rather easy for the compiler actually. Agreed that it provides a slight extra burden on the human reader. But I don't think it is significantly larger than the current burden of knowing the definition site of a function.
I believe there should be a clean separation between - constructing the global module namespace, and - interpreting the source code of a module
OK, but that is in direct conflict with the original proposal (to specify a package alongside a module import), which abandons the idea of a "global" module namespace! Indeed, the whole motivation was that we _don't_ want a global module namespace, because that would require all modules in all packages to have unique names.
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.
At the moment, the compiler must search the filesystem, package database, and *interface files* (for imports/re-exports). With explicit namespaces, nothing changes there (except that namespaces must also be recorded in the interface files). Regards, Malcolm