The FunctorM library

[Keean Schupke]

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.

    Keean.

Josef Svenningsson wrote:

>On Wed, 23 Mar 2005 09:49:43 -0000, Simon Marlow <simonmar at microsoft.com> 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.
>
>/Josef
>_______________________________________________
>Libraries mailing list
>Libraries at haskell.org
>http://www.haskell.org/mailman/listinfo/libraries
>  
>