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