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.