Module System

Georg Martius mai99dgf at
Tue Feb 21 10:06:41 EST 2006


I have some proposals for changes of the hierarchical module system as it is 
at the moment.
- 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. 

	- allow much easier refactoring at package level.
	- reduce redundancy between file location and file content
	- 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. 

	- Again, easier refactoring at package level
	- 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

	- Much less imports
	- easy use of large libraries like Graphics.UI.Gtk
	- 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.

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



More information about the Haskell-prime mailing list