Re: The FunctorM library

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 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@haskell.org http://www.haskell.org/mailman/listinfo/libraries