RE: Proposal: Applicative => Monad: Call for consensus

Bas van Dijk wrote:

On 20 January 2011 10:58, Henning Thielemann 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 ===============================================================================