On Fri, Nov 27, 2015 at 9:42 AM, Herbert Valerio Riedel
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