You're asking for a new top-level name Monad. My implession from SimonM's library document is that the intention is that top-level names are to be limited (and certainly only added by agreement). In this particular case monads don't seem broad enough to be a category of their own, and they are a sort of control structure. Hierarchical libraries mean changing our expectations about module name length (e.g. Graphics.Rendering.OpenGL.GLU.Tessellation and the like). Lucky Haskell has import aliases. i am not sure what should we put unedr Monad.* if not the monad library. my preference is to use the hirarchical module system to avoid name clashes rather than for classification purposes. and i don't think any hirarchy much deeper than about 4 would be practical, even with aliases. long names are good from software engineering perspective, but only up to a point. this is why i think it is appropriate for the monad library to be in Monad.*. as simon pj pointed out in a talk he gave, it was
BTW, I've been assembling a small arrow transformer library, and many of the structuring issues are similar. One issue is how fine grained the modules should be. You have a module (Unstable.)Control.Monad.Trans containing transformer classes and also several monad classes. Those monad classes don't necessarily belong in the transformer module; you could even have one module for each. With the monolithic module, users are more likely to need explicit import clauses. yes, i agree that this is a tricky one. the choices i made were either
hello, Ross Paterson wrote: probably a mistake to choose such a wierd name for the concept, but hey now we at least won't have name clashes :-) based on what was already in the library, or what i thought would be the most common usage pattern. i am inclined to try an minimize the number of imports as long as that does not lead to too much name pollution. i've had discussions with people who even prefer having _all_ transformers in a single file, so that you can simply import Monad.Transformers and be done with it. to accomodate such users i added the Transformers file that imports all transformers.
Another issue: typically one works with a stack of transformers sitting on a base monad. You have functions for adding or removing a transformer from the top of the stack, and for manipulating the base monad. It might also be useful to have something to remove a State transformer from anywhere in the stack, etc. i've tried to do things like that, but i can't figure out a way to achieve them. what would be the type of such a function? something like:
runInnerState :: (Monad n, MonadState s m) => s -> m a -> n a (and n is the same as m,but without the state component). thanks for the comments iavor -- ================================================== | Iavor S. Diatchki, Ph.D. student | | Department of Computer Science and Engineering | | School of OGI at OHSU | | http://www.cse.ogi.edu/~diatchki | ==================================================