<div dir="ltr">Unbiased sounds good to me.<div><br></div><div>That's a good point, Mario.  I'm in favor of the modernization, but I don't have a strong preference that it happen along with this other change.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 25, 2017 at 3:43 PM, Michael Snoyman <span dir="ltr"><<a href="mailto:michael@snoyman.com" target="_blank">michael@snoyman.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">On Thu, May 25, 2017 at 11:38 AM, Mario Blažević <span dir="ltr"><<a href="mailto:mblazevic@stilo.com" target="_blank">mblazevic@stilo.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=""><span>On 2017-05-25 12:55 PM, David Feuer wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
A lot of people have wrappers around Data.Map and Data.IntMap to give them more useful (Semigroup and) Monoid instances. I'd like to add such wrappers to containers. What we need to be able to do that are *names* for the new modules. I can't think of any, so I'm reaching out to the list. Please suggest names!<br>
</blockquote>
<br></span></span>
Data.Map.Monoidal is not strictly correct but would give a pretty good idea at first glance.<br>
<br>
Data.Map.Symmetric would be more correct, since its Semigroup and Monoid instances would be symmetric, with no preference for the left argument as currently.<span><br>
<br>
<br></span></blockquote><div><br></div><div>Just to throw out an option here: Unbiased. I don't feel strongly about it, but thought throwing it out may be helpful.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><span>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Another question is whether we should take the opportunity of new modules to modernize and streamline the API a bit. I'd like, at least, to separate "safe" from "unsafe" functions, putting the unsafe ones in .Unsafe modules.<br>
</blockquote>
<br></span></span>
        I think it would be better to keep the API exactly the same, much like Data.Map.Strict does. I don't want to think about the incidental API differences when I switch from one module to another. If you're going to modernize, modernize all the modules at once. That's what version numbers are for.<br></blockquote><div><br></div><div>+1. I'd also argue against changing the API right now.<span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888"><div>Michael <br></div></font></span></div></div></div>
<br>______________________________<wbr>_________________<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-<wbr>bin/mailman/listinfo/libraries</a><br>
<br></blockquote></div><br></div>