Proposal: Applicative => Monad: Call for consensus

Bas van Dijk v.dijk.bas at
Thu Jan 20 14:11:20 CET 2011

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




More information about the Libraries mailing list