Proposal: Applicative => Monad: Call for consensus

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


Bas van Dijk wrote:
> On 20 January 2011 10:58, Henning Thielemann
> <lemming at henning-thielemann.de> 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 :-)

Ganesh

=============================================================================== 
Please access the attached hyperlink for an important electronic communications disclaimer: 
http://www.credit-suisse.com/legal/en/disclaimer_email_ib.html 
=============================================================================== 




More information about the Libraries mailing list