<div dir="ltr">Until we get rid of (>>) from Control.Monad and we can then rely upon (*>) and (>>) having the same performance characteristics mapM_ and traverse_ are not interchangeable. I realize you didn't say anything about those functions, but hear me out.<div><br></div><div><div>The tentative migration plan is, assuming the "monad of no return" proposal goes through, to first eliminate (>>) then fix mapM_. This avoids the very awkward intermediate state that would be a result of directly implementing your proposal here where mapM_ needs a stronger constraint (Monad) than mapM does, which would use Applicative!</div><div><br></div><div>I therefore very strongly advocate waiting for the elimination of (>>) through the monad of no return proposal before we proceed with any simplification of Traversable.</div><div><br></div><div>-Edward</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Sep 26, 2015 at 5:05 PM, David Feuer <span dir="ltr"><<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">Traversable currently has traverse, sequenceA, sequence, and mapM methods. sequence and mapM seem to be dinosaurs now. I'd like to suggest that sequenceA be turned into a deprecated function and mapM be moved from Control.Monad to Data.Traversable and re-exported from Control.Monad.</p>
<p dir="ltr">I expect most instance declarations to survive unchanged. The only CPP pain point will be that instances that define sequenceA will have to define sequence instead.</p>
<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>
<br></blockquote></div><br></div>