MRP Summary & revised MRP 2ed

[Akio Takano]

On Fri, Nov 27, 2015 at 9:42 AM, Herbert Valerio Riedel
<hvriedel at gmail.com> wrote:
> You're right, from what I've seen the majority of Monad instances don't
> bother to override (>>)/(*>) currently.
>
> But do we really want every Applicative/Monad to explicitly define (*>)
> (and consequently (>>)=(*>)) ?

You are right, this indeed seems like a strange thing to require.
However I believe that this is much better than silently changing the
default definition for (>>) to something that potentially has worse
asymptotic behaviors.

Of course another option is to keep (>>) in the Monad class.

- Akio

>
> If so, it seems to be unfortunate that we have an overridable default
> implementation for (*>)/(>>) in place, as that IMO suggests that you're
> only supposed to override (*>) in those less common cases where it
> provides a benefit over the default implementation. What's the point of
> the default implementation otherwise?
>
>
> -- hvr