hirarchical modules

[Ross Paterson]

On Thu, May 29, 2003 at 11:57:00AM -0700, Iavor Diatchki wrote:
> [...] and don't 
> you think the code bellow is better?  not to mention that moving the 
> library to a new localtion would be practically for free (as far as the 
> library is concerned, the users may still have to adjust their imports)
> 
> >      module State (State,runState,runStateS,module Trans) where
> >
> >      import Identity
> >      import StateT
> >      import Trans
> >
> >      type State s  = StateT s Identity
> >
> >      runState      :: s -> State s a -> a
> >      runState s m  = runIdentity (StateT.runState s m)
> >
> >      runStateS     :: s -> State s a -> (a,s)
> >      runStateS s m = runIdentity (StateT.runStateS s m)

I believe you need a qualified on the import of StateT to avoid ambiguity.
But you would get the same effect with a variant of Malcolm's version:

	module Control.Monad.State (
		State,runState,runStateS,module Trans) where

	import           Control.Monad.Identity as Identity
	import qualified Control.Monad.StateT   as StateT
	import           Control.Monad.Trans    as Trans

with the rest of the module unchanged.  Further changes would be required
only

(1) to export the whole of the current module

(2) if names needed to be qualified with the name of the current
    module to avoid ambiguity (quite rare -- only one module does it
    in fptools/{libraries,hslibs}, and that unnecessarily)

In both cases you'd need to specify the module name with or without your
extension, the only difference is its length.  Even that could be fixed
in Haskell 98, where you could write

	import           Control.Monad.State as State

but none of the implementations would like it.

The current setup is cumbersome, but the verbosity can be confined to
the module header and the imports, except in the rare case (2) above.
And it is simple: the name mentioned in the import is the real module
name.