Proposal: Applicative => Monad: Call for consensus

Sittampalam, Ganesh ganesh.sittampalam at
Thu Jan 20 14:24:36 CET 2011

Bas van Dijk wrote:
> On 20 January 2011 10:58, Henning Thielemann
> <lemming at> wrote: 
>> Wolfgang Jeltsch wrote:
>>> If both (>>=) and join are class methods with default
>>> implementations that use the respective other method, you can still
>>> define the Cont monad instance in terms of (>>=), while you can use
>>> join where it is easier (e.g. in the [] instance). So instead of
>>> arguing whether join or (>>=) is easier, more natural or whatever,
>>> just let us make both a method of Monad.
>> Does anyone want to comment on my comparison with restricted monads,
>> where '>>=' can be defined, but 'join' cannot?
> Just for clarity, are you referring to the restricted monads from the
> rmonad package[1]? 
> If so, I see no reason (yet) why the RMonad type class can't be
> defined as: 
> class RMonad m where
>    join :: Suitable m a => m (m a) -> m a
> Where the Set instance becomes:
> instance RMonad Set where
>    join ss = withResConstraints $ \SetConstraints -> fold union empty
> ss 

I haven't tried it, but I think you'd need Suitable m (m a) in the
constraints, either of join itself, or of (>>=) to make the default
definition typecheck.

I ran into similar problems with trying to make RApplicative. Many of
the Applicative combinators use intermediate functions heavily, leading
to a need for Suitable m (a -> b) for various a and b, and there are
often multiple different possible definitions of the combinators that
lead to different constraints being needed.

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 :-)


Please access the attached hyperlink for an important electronic communications disclaimer: 

More information about the Libraries mailing list