Hello,<div><br><div>-1 for me too, for the reasons already discussed in the thread (i.e., because it makes it easy to accidentally ignore potentially important results). I think that gains in readability from this generalization are at best questionable.</div>
<div><br></div><div>-Iavor</div><div><br></div><div><br></div><div><br></div><div><br><div class="gmail_quote">On Tue, Jun 5, 2012 at 2:07 PM, Andres Löh <span dir="ltr"><<a href="mailto:andres@well-typed.com" target="_blank">andres@well-typed.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">> Btw. the mapM memory leak can be easily and accidentally resurrected by<br>
> writing<br>
><br>
> when_ b (mapM f xs)<br>
><br>
> with<br>
><br>
> f :: a -> m ()<br>
> when_ :: Bool -> m a -> m ()<br>
<br>
</div>I don't understand the whole mapM analogy (yet). I don't need when_ to<br>
get into trouble with using mapM. Also, whether a space leak with mapM<br>
arises or not typically doesn't depend on whether you use its result<br>
or not. It's the other way round: if you run mapM on a huge list but<br>
aren't interested in the results, then you should use mapM_ instead.<br>
So the problem here is accidentally producing a (large) result rather<br>
than accidentally ignoring it.<br>
<div class="HOEnZb"><div class="h5"><br>
Cheers,<br>
Andres<br>
<br>
--<br>
Andres Löh, Haskell Consultant<br>
Well-Typed LLP, <a href="http://www.well-typed.com" target="_blank">http://www.well-typed.com</a><br>
<br>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org">Libraries@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/libraries" target="_blank">http://www.haskell.org/mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br></div></div>