The FunctorM library
k.schupke at imperial.ac.uk
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 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.
>Libraries mailing list
>Libraries at haskell.org
More information about the Libraries