<div dir="ltr"><div>We managed to show that the old counter-example of a mapM that works where traverse that would blow the stack isn't an issue since <a href="https://ghc.haskell.org/trac/ghc/ticket/8189">https://ghc.haskell.org/trac/ghc/ticket/8189</a> was resolved.</div><div><br></div>Consequently, we're looking at removing mapM entirely from the class and just making it a top level definition.<div><br></div><div>To do that we'd need to deprecate redefinition of the method in instances for a version or two. This would need a new form of deprecation, where you deprecate redefinition but not use of a member of a class. (I think Herbert filed an issue to create it, but I can't find it off hand.)</div><div><br></div><div>Once we can make that transition, then the constraints on mapM would relax to the same as those for traverse. That would fix both the constraints and the implementation going forward for everything, but we should probably handle this particular case first or you won't see any benefit for a couple of years.</div><div><br></div><div>-Edward</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 12, 2015 at 11:58 AM, Simon Marlow <span dir="ltr"><<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 12/05/2015 15:26, Edward Kmett wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
On Tue, May 12, 2015 at 3:58 AM, Simon Marlow <<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a><br></span><span class="">
<mailto:<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a>>> wrote:<br>
<br>
<br>
    Yes, I'm not really concerned that mapM is a method of Traversable<br>
    rather than just being an alias for traverse, but I'm wondering why<br>
    we define it in the list instance rather than using the default.<br>
<br>
<br>
We were pretty paranoid about introducing space or time regressions and<br>
didn't have a proof that we wouldn't introduce them by changing<br>
something there, so we left it alone.<br>
</span></blockquote>
<br>
Ok good, so it looks like the answer is "we could change it, but benchmark first".  I can do that.  Thanks!<br>
<br>
Cheers,<br>
Simon<br>
</blockquote></div><br></div>