<div dir="ltr">I'm personally -1 from a base organizational standpoint following Reid's reasoning. <div><br></div><div>This is just me expressing my own personal opinion rather than any official core libraries committee stance at this time.<div><br></div><div>-Edward</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 31, 2015 at 1:19 PM, Petr Pudlák <span dir="ltr"><<a href="mailto:petr.mvd@gmail.com" target="_blank">petr.mvd@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="">2015-08-31 21:00 GMT+02:00 David Feuer <span dir="ltr"><<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><p dir="ltr">The theory of mconcat is that it should handle monoids that need to be summed in some special way. I don't know if anyone actually uses it so, however. Still, Reid is right that the circular dependency sets a very high bar.</p>
<div class="gmail_quote"><div><div><br></div></div></div></blockquote></span><div>I guess the [a] monoid is a good example where using mconcat can make a difference.</div><div><br></div><div>What seems to be an omission is that Dual has no implementation of mconcat. It'd make sense to define 'mconcat = mconcat . reverse' - if the original monoid benefits from a certain order of operations, we should keep the order.</div></div></div></div>
<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>