Proposal: Applicative => Monad: Call for consensus

[Dan Doel]

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