Proposal: Applicative => Monad: Call for consensus
Dan Doel
dan.doel at gmail.com
Thu Jan 20 21:51:53 CET 2011
On Thursday 20 January 2011 8:24:36 am Sittampalam, Ganesh wrote:
> My suspicion is that the monad/applicative laws imply some rules about
> the Suitable instances, but I haven't thought this through properly. In
> that sense RMonad is something of an unprincipled hack :-)
RMonad is actually given a category theoretic analogue in Monads Need Not Be
Endofunctors.* There one has:
Two categories J and C
A functor F : J -> C
A mapping T of J objects to C objects
A family of morphisms eta_A : JA -> TA for each object A of J
For A,B objects of J, and k : JA -> TB, k* : TA -> TB
satisfying some monad-like laws. For RMonad we have (I think this is close):
J is some full subcategory of C = Hask identified by Suitable
F is the inclusion functor from J to Hask
T is the RMonad type constructor
eta : forall a. Suitable m a => a -> m a
ext : forall a b. (Suitable m a, Suitable m b) => (a -> m b) -> m a -> m b
But T cannot be composed with itself, obviously. So join doesn't make sense.
However, you can also count me as another person who doesn't care what
difficulties exist for RMonad with regard to deciding what functions should go
in the Monad class. I think both (>>=) and join should be in the latter.
-- Dan
[*] http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.156.7931
More information about the Libraries
mailing list