Proposal: Applicative => Monad: Call for consensus

[Gábor Lehel]

On Tue, Jan 18, 2011 at 10:00 AM, Wolfgang Jeltsch
<g9ks157k at acme.softbase.org> wrote:
> Am Montag, den 17.01.2011, 19:24 -0500 schrieb Jan-Willem Maessen:
>> I think Tyson Whitehead unwittingly made my point rather well using
>> the example of the CPS monad.  I believe his simple explanation of
>> join in CPS actually leads to an incorrect definition, whereas
>> explaining >>= in CPS is about as straightforward as anything
>> involving CPS can be (which is to say, more than a little convoluted).
>
> 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.

Right. "Easier" is something of a subjective quality. A significant
share of the people contributing to this thread have expressed the
sentiment that they find join easier, at least for many Monads, and I
find it unlikely that any amount of reasoned debate is going to
convince them that their subjective experiences aren't what they are.

The question becomes whether the benefits of making join a method --
making it easier and more obvious for these people to define their
Monads using join -- outweigh the costs: having another method in the
Monad class, the sense that this is unnecessary, GHC potentially not
optimizing it as well in do statements, and that in some cases for
some people join+fmap would be harder and/or more verbose/duplicative
to define than bind and they might accidentally define join+fmap
instead when they should've used bind(?).


>
> Best wishes,
> Wolfgang
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>



-- 
Work is punishment for failing to procrastinate effectively.