<div dir="ltr">I don't have benchmarks that support the removal of sequenceA at this time. I also don't have ones that support its retention, but at this stage removal has the higher burden of proof.<div><br></div><div>We should eventually be able to eventually kick sequence and mapM out of the class and simultaneously weaken their constraints, so assuming that much happens you'll eventually be able to use sequence as sequenceA. The question then becomes if we'll be able to eliminate sequenceA as well, or if it should remain in the class.</div><div><br></div><div>None of these migrations paths viably end with sequence being a member of the class, though, so the best case is that we find `traverse id` is never appreciably worse and can separately move sequence/sequenceA out of the class. Otherwise we'd be left with the annoyance of defining sequenceA.<br></div><div><br></div><div>Unfortunately the same issue mentioned above regarding the relationship between mapM and mapM_ applies mutatis mutandis to sequence and sequence_, so we can't really weaken the constraint on sequence until the monad of no return proposal extended with (>>) goes through, putting both potential simplifications of the Traversable class on the same general clock.</div><div><br></div><div>-Edward</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Sep 26, 2015 at 5:32 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">Argh. I'd love to be able to deprecate sequenceA sooner rather than later. Are there polymorphic recursive settings where sequenceA is more efficient than traverse id? If not, we can start sinking it immediately; if so, we have to wait for sequence to be ready to take its place.</p><div class="HOEnZb"><div class="h5">
<div class="gmail_quote">On Sep 26, 2015 5:21 PM, "Edward Kmett" <<a href="mailto:ekmett@gmail.com" target="_blank">ekmett@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><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" target="_blank">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>
</blockquote></div>
</div></div></blockquote></div><br></div>