Hello,

I have some proposals for changes of the hierarchical module system as it is 
at the moment.
Goals:
- easy refactoring at Module/Package level
- easier import/export of trees of modules (useful for any larger library)
	- relative imports/exports
	- deep import or export lists

Notation: I use "X --> Y" to mean X is an example how it is now and Y is my 
proposed version.

1) Instead of writing the full name of the module in the head line it should 
be allowed to just use its last part e.g. 
module  System.Posix
-->
module Posix

The hierarchical name can be derived from the place in the filesystem. 

Pros:
	- allow much easier refactoring at package level.
	- reduce redundancy between file location and file content
Cons:
	- loose location information in file itself

2) relative imports/exports: imports/exports of submodules can be specified 
as a relative path:

module System.Posix 
	( module System.Posix.Env ) where
import System.Posix.Env
-->
module Posix 
	( module .Env ) where
import .Env

or whatever syntax you prefere. 

Pros:
	- Again, easier refactoring at package level
Cons:
	- the "." might be overseen (I expect long syntax discussions  )

3) Import subtrees:

import (qualified) System.Posix.* as P
would to the same as
import (qualified) System.Posix.Directory as P.Directory
import (qualified) System.Posix.Env as P.Env
import (qualified) System.Posix.DynamicLinker as P.DynamicLinker
import (qualified) System.Posix.DynamicLinker.Module as P.DynamicLinker.Module
....

Pros:
	- Much less imports
	- easy use of large libraries like Graphics.UI.Gtk
Cons:
	- More modules are imported than necessary 

4) Export subtrees:
This proposal seems to do the same thing as 3) but on the side of the library 
not on the calling side.
-----------------
module System
	( module P.*
	) where
import qualified Posix.* as P
------------------
module Test where
import System
-- Posix.Env is in scope now

The details about the qualification must be sorted out carefully, but I see no 
serious problem there at the moment.

Pros:
	- Easy writing of meta-modules
	- avoids name clashing within submodules (e.g. Data.Map, Data.Set,... which 
have all insert, lookup,...)
Cons:
	- importing side does not see, that there is a whole tree imported.

Comments?

Cheers,
	Georg