monad transformer library (was: in list transformer)

[Ross Paterson]

On Wed, Jun 04, 2003 at 11:38:16AM -0700, Iavor Diatchki wrote:
> well, in the old library there didn't seem to be a particular structure
> (perhaps this is what you mean by diagonal).  for example:
>  * the instance that StateT is a writer (if underlying monad is a 
> writer) is in State.hs
>  * the instance that ReaderT is a writer (if underlying monad is a 
> writer) is in Writer.hs

The structure was that the monads were arranged in a sequence:

	Reader, Writer, State, RWS, Cont, Error, List

Module n would import modules 1..n-1, introduce Mn and corresponding
classes, make Mn an instance of all earlier classes and make previous
monads instances of the new classes.  If you picture a matrix of types
vs classes, it was walking down the diagonal.

As for where to place instances, SimonM has the following in the
(much-overlooked) library document:

	A module corresponding to a class (e.g. Bits) contains the class
	definition, perhaps some auxiliary functions, and all sensible
	instances for Prelude types, but nothing more. Other modules
	containing types for which an instance for the class in question
	makes sense contain the code for the instance itself.

which makes sense to me, though maybe I'd put several classes in one
module.

> >Resumptions may be generalized to
> >
> >	newtype ResumeT f m a   = Re { unRe :: m (Res f m a) }
> >	data Res f m a          = Value a | Delay (f (ResumeT f m a))
> >
> >where f is a functor.
> 
> interesting, i hadn't seen that. this will also make the Resume monad a 
> little more interesting
> (it used to be kind of like the natural numbers).  i'll add that.  is 
> there a paper where they discuss that?  i also haven't really proved the 
> monad laws, hopefully they still work.

One of Moggi's later ones, I think.