Proposal: Applicative => Monad: Call for consensus
Bas van Dijk
v.dijk.bas at gmail.com
Thu Jan 20 14:11:20 CET 2011
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
Regards,
Bas
[1] http://hackage.haskell.org/package/rmonad
More information about the Libraries
mailing list