<div dir="ltr">(>>) becomes slower by default in some cases and drastically faster in others, but since the definition is a member in a class it can actually be fixed by people.<div><br></div><div><div>In situations where (<*>) is asymptotically more efficient than (>>=) then the default definition in terms of (<*>) wins.</div><div><br></div><div><div>Right now, if you run through hackage there are lots of places where (>>) has been manually improved but the (*>) has not -- or vice versa. We have two places where people should apply an optimization and many have only realized that they should optimize one or the other.</div><div><br></div><div>The key here is to encourage folks to actually define (*>) when it matters.</div><div><br></div><div>-Edward</div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Nov 25, 2015 at 2:37 AM, Akio Takano <span dir="ltr"><<a href="mailto:tkn.akio@gmail.com" target="_blank">tkn.akio@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Herbert,<br>
<span class=""><br>
On Thu, Nov 5, 2015 at 10:46 AM, Herbert Valerio Riedel <<a href="mailto:hvr@gnu.org">hvr@gnu.org</a>> wrote:<br>
> Hello everybody,<br>
><br>
> Based on the feedback gathered from the discussion, the proposal has<br>
> been revised to address the raised concerns. The highlights are:<br>
><br>
> - A new stretched out transition scheme complying with the recently<br>
> enacted 3-release policy (and beyond) has been devised.<br>
><br>
> - Unifying `>>`/`*>` has been incorporated into the proposal in the<br>
> interest of bundling changes of obviously related changes.<br>
><br>
> - Moreover, the feasibility of automatic refactoring tooling was<br>
> investigated and resulted in the working `Hs2010To201x`<br>
> proof-of-concept.<br>
><br>
> Please re-read the revised proposal at<br>
><br>
> <a href="https://ghc.haskell.org/trac/ghc/wiki/Proposal/MonadOfNoReturn" rel="noreferrer" target="_blank">https://ghc.haskell.org/trac/ghc/wiki/Proposal/MonadOfNoReturn</a><br>
><br>
> for more details (or use the Wiki's diffing feature to see what changed<br>
> relative to the original revision) if you want to comment, so we can<br>
> focus on discussing the actual revised version.<br>
<br>
</span>I'm sorry to join the discussion so late, but I'd like to mention one<br>
thing that doesn't seem to have been brought up. If I understand<br>
correctly, this proposal can silently slow down existing programs,<br>
sometimes even asymptotically. This applies when a monad is defined<br>
with no explicit definition for (>>) nor for (*>).<br>
<br>
The problem is this: currently, when a Monad instance lacks an<br>
explicit definition for (>>), a default implementation based on (>>=)<br>
is used. After this proposal, (>>) would be an alias for (*>), for<br>
which there is a default implementation based on (<*>). However, at<br>
least for some monads, the former is a much better default.<br>
<br>
[1] is one example where it makes an asymptotic difference in runtime.<br>
This type of difference arises when (>>=) has to linearly traverse its<br>
LHS, but not its RHS.<br>
<br>
[1] <a href="https://ghc.haskell.org/trac/ghc/ticket/10711#comment:1" rel="noreferrer" target="_blank">https://ghc.haskell.org/trac/ghc/ticket/10711#comment:1</a><br>
<br>
I also constructed another example [2]. This is a standard<br>
implementation of the strict State monad, except that (>>=) is<br>
implemented as a NOINLINE function. You can see that using (*>) in<br>
place of (>>) changes the memory usage of the program from constant to<br>
linear. The difference here arises from the fact that the default<br>
implementation for (>>) can "tail-call" its RHS as long as (>>=) also<br>
has this tail-call property, but the default implementation of (*>)<br>
cannot.<br>
<br>
[2] <a href="https://gist.github.com/takano-akio/7066c511b60d6ab090c5" rel="noreferrer" target="_blank">https://gist.github.com/takano-akio/7066c511b60d6ab090c5</a><br>
<br>
In my opinion introducing this kind of performance regression is quite<br>
bad. Although I agree that it's frustrating that we are stuck with<br>
mapM, mapM_ etc., I believe this should be fixed in a way that doesn't<br>
make (>>) slower by default.<br>
<br>
Regards,<br>
Takano Akio<br>
<span class="im HOEnZb"><br>
><br>
> Also, as per proposal guidelines, and more importantly, for the benefit<br>
> of those that lost track of this rather complex discussion, I've tried<br>
> to summarize the core of discussion over at<br>
><br>
> <a href="https://ghc.haskell.org/wiki/Proposal/MonadOfNoReturn/Discussion" rel="noreferrer" target="_blank">https://ghc.haskell.org/wiki/Proposal/MonadOfNoReturn/Discussion</a><br>
><br>
> More importantly, based on feedback gathered as well as concerns raised<br>
> throughout the discussion, I've revised and extended the proposal into a<br>
> "2nd edition MRP". I feel confident the new revised proposal addresses<br>
> the major concerns as well as adhering to the recently requested 3-yr<br>
> compatibility policy.<br>
><br>
> PS: One common oversight I noticed when reviewing the discussion is<br>
> that the last-minute proposal addition -- of unifying `>>`/`*>` in<br>
> the same vein as `pure`/`return` -- wasn't noticed by many who<br>
> joined the debate late.<br>
><br>
> However, Unifying `>>`/`*>` and `pure`/`return` are in my opinion<br>
> strongly related concerns as they share the same rationale about<br>
> correctness issues and it doesn't make sense to do one without the<br>
> other. However, the transition time-scales could be set slightly<br>
> different to account for the more breaking nature of effectively<br>
> changing `>>`'s current default method operational semantics.<br>
><br>
> Thanks,<br>
> Herbert<br>
><br>
</span><div class="HOEnZb"><div class="h5">> _______________________________________________<br>
> Libraries mailing list<br>
> <a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
><br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br></div>