hello, Hal Daume III wrote:

This was brought up before:

http://www.haskell.org/pipermail/libraries/2002-February/000552.html

and then again before that I think I wrote something about it, but can't find the message. Needless to say, I think this would be *very* nice, but there didn't seem to be support from the powers that be.

i am aware that there have been previous discussions on the subject, but they seem to have had no results (who are the powers that be? :-). and i could see no good reason as to why. simply because simon doesn't mind writing out 40 character imports doesn't mean that we have a good design. the flaws i pointed out seemed kind of obvious. perhaps i should be more concrete. here is an example:

module Control.Monad.Experimental.State (State, Control.Monad.Experimental.State.runState, Control.Monad.Experimental.State.runStateS, module T) where

import Control.Monad.Experimental.Identity import Control.Monad.Experimental.StateT as S import Control.Monad.Experimental.Trans as T

type State s = StateT s Identity

runState :: s -> State s a -> a runState s m = runIdentity (S.runState s m)

runStateS :: s -> State s a -> (a,s) runStateS s m = runIdentity (S.runStateS s m)

suggestions on how to rewrite the imports/exports above more concisely are welcome. by the way the changes i suggested before (and i am sure others must have pointed out) would allow me to write this module in the usual haskell way (which at least in this case seems vastly superior). and then the module would be compatable with systems that do not implement the hirarchical module extension. bye iavor

As for moving things around, the suggestion I got was to use a quick 'grep' to change the module names :). Very efficient.

- Hal

-- Hal Daume III | hdaume@isi.edu "Arrest this man, he talks in maths." | www.isi.edu/~hdaume

On Wed, 28 May 2003, Iavor Diatchki wrote:

...

hello,

i was wondering how final is the design of the hirarchical module system for haskell? i have been working on the monad library for the past week or so and this is my first experience with the hirarchical module system in a real project. i must say that i find it very cumbersome.

here is why: the whole monadic library is in the same directory, but since there is no way to use relative names, all the imports use the rather long fully qualified name. things like:

import Control.Monad.X.ReaderT

are very common. and if the hirarchy gets deeper, names will get longer. while the verbosilty is annoying there is a more serious problem. moving code around is very work intensive (and error prone). for example, when i decide that what i have is stable enough i'd like to move it to the Control.Monad part of the library (i.e. get rid of the X). that means that i have to go and change all the imports, and all the module names.

of course i have a haskell lexer at my disposition so i have a little program to do that for me, but that solution seems very unsatisfactory.

and there seems to be a rather obvious solution to this problem: 1. allow for imports relative to the location of the importing module 2. remove the requirement that the path to a module is hardcoded in the module name.

i am now hoping that someone will say: yes we already tought of that and it is indeed supported... any thoughts?

bye iavor

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries

hello, Malcolm Wallace wrote:

The "powers that be" are the compiler maintainers. If you can't persuade them (all) to adopt your proposal, then de facto it won't fly. But by-and-large, we are reasonable people. :-) You just need to be sufficiently persuasive. hmm... what should i do? implement 50 libraries using the broken system just to illustrate that it is broken?

...

suggestions on how to rewrite the imports/exports above more concisely are welcome.

The exports at least can be made shorter as follows.

module Control.Monad.Experimental.State (State, ,runState ,runStateS ,module T) where

import Control.Monad.Experimental.Identity import qualified Control.Monad.Experimental.StateT as S import qualified Control.Monad.Experimental.Trans as T

type State s = S.StateT s Identity

runState :: s -> State s a -> a runState s m = runIdentity (S.runState s m)

runStateS :: s -> State s a -> (a,s) runStateS s m = runIdentity (S.runStateS s m)

yes, i was also thinking of that, and it works for this particular case. i didn't like it becasue it means that i have to use qualified names everywhere in the module. and i have to do that not to avoid clashes, but so that i can write a shorter entry in the exoprt list. 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)

bye iavor

...

import Control.Monad.Experimental.Identity import Control.Monad.Experimental.StateT as S import Control.Monad.Experimental.Trans as T

I personally don't mind the typing much, that is the least of my concerns. :-) What "concerns" me though, is the fact that a module must know its own place in the hierarchy. It must know it's "Foo.Bar.Me" rather than just knowing it's "Me". This makes it hard to move modules, as has been mentioned already, and it's information the module simply doesn't _need_. So unless there is a technical necessity to reveal this information -- and I wouldn't know any -- I'm all for getting rid of specification of the full path. By the way, C++'s namespaces have almost the same deficit and they effectively failed to fulfill their purpose because of it. (I can elaborate this, if anyone's interested in my opinion. I believe much can be learned from C++'s strengths and weaknesses today.) Peter