On Fri, Jul 25, 2003 at 12:40:22AM +0200, Iavor Diatchki wrote:
2. currently the monad library is under Unstable.Control.Monad, and i would like to move it to some other place, so that we can use it, without the need to later rename everything. the core of it should be more or less stable. since moving libraries at the moment is quite work intensive, it would be nice if we agreed on where to put it, so that we don't have to move it again. i propose that we put all the monads under Monad, thus one would import Monad.State, Monad.ReaderT, or Monad.Transformers. in this way the old monad library can stay under Control.Monad and programs that are using it need not change. at some point in the future we can decide to remove the old library or it can just stay there. and i like the shorter names (not to mention that it is not clear what some of the monads have to do with control).
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. 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. 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.