Home
Reading
Searching
Subscribe
Sponsors
Statistics
Posting
Contact
Spam
Lists
Links
About
Hosting
Filtering
Features Download
Marketing
Archives
FAQ
Blog
 
Gmane
From: Georg Martius <mai99dgf-km4yhOgQYaVr3jNxy2a9CfCA2rUS1Xrh <at> public.gmane.org>
Subject: Module System
Newsgroups: gmane.comp.lang.haskell.prime
Date: Tuesday 21st February 2006 15:06:41 UTC (over 11 years ago)
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
 
CD: 3ms