monad library

[Iavor Diatchki]

hello,

Ross Paterson wrote:
> 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 
probably a mistake to choose such a wierd name for the concept, but hey 
now we at least won't have name clashes :-)

> 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 
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               |
==================================================