The FunctorM library

Keean Schupke k.schupke at
Wed Mar 23 06:24:53 EST 2005

What about pre-monads, co-monads, and monoids? (insn't a monad just a 
monoid where the operators are natural transformations?)...

What is the next category after monads?

Wouldn't a "category" library make sense, with a larger range of 
categories, and with "class" constraints enforced so, if category theory 
says a monad must be a functor - then we should have:

class CategoricalFunctor m => CategoricalMonad m ...

which gets the compiler to 'proove' the relationship for all instances.


Josef Svenningsson wrote:

>On Wed, 23 Mar 2005 09:49:43 -0000, Simon Marlow <simonmar at> wrote:
>>Does anyone else have any comments on the suggestions from Iavor and Thomas in this thread?  I'm happy to make changes, but only if there's a concensus.  The proposals so far seems to be
>>  1) add dist method
>>  2a) make Functor a superclass of FunctorM
>>  2b) make Functor a *sub*class of FunctorM
>>  2c) make Functor a subclass of Monad
>>  2d) make Functor a superclass of Monad
>>  3) rename FunctorM class to ForEach
>>  4) rename FunctorM module to Control.Monad.FunctorM(?)
>>(1) is easy and not controversial (but is 'dist' the best name?).
>>AFAICT, 2a, 2b, 2c, and 2d have all been suggested (eg. the quoted message above suggests 2a, 2b and 2c).  Perhaps some of the suggestions were typos, but at this point I'm a bit confused!
>I think 2c) and 2d) are no go since they violate the Haskell Report.
>Apart from that I support 1).
>Just my 2 öre.
>Libraries mailing list
>Libraries at

More information about the Libraries mailing list