<div dir="ltr">There's also some nice interplay here with 'coerce', namely that by coercing NewMap k v to Map k (Data.Semigroup.First v), we can recover the original behavior.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 25, 2017 at 6:10 PM, 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="">On 2017-05-25 04:08 PM, David Feuer wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Unbiased sounds nice, but I'm a bit concerned that it might suggest<br>
bigger differences than just the Monoid instance. I assume people<br>
still want the same left-biased union function.<br>
</blockquote>
<br></span>
I agree. Quite apart from the compatibility issues, I'd rather use mappend or (<>) once the instances are fixed than any union function, biased or not.<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On Thu, May 25, 2017 at 3:43 PM, Michael Snoyman <<a href="mailto:michael@snoyman.com" target="_blank">michael@snoyman.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<br>
On Thu, May 25, 2017 at 11:38 AM, Mario Blažević <<a href="mailto:mblazevic@stilo.com" target="_blank">mblazevic@stilo.com</a>><br>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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">
<br>
A lot of people have wrappers around Data.Map and Data.IntMap to give<br>
them more useful (Semigroup and) Monoid instances. I'd like to add such<br>
wrappers to containers. What we need to be able to do that are *names* for<br>
the new modules. I can't think of any, so I'm reaching out to the list.<br>
Please suggest names!<br>
</blockquote>
<br>
<br>
Data.Map.Monoidal is not strictly correct but would give a pretty good<br>
idea at first glance.<br>
<br>
Data.Map.Symmetric would be more correct, since its Semigroup and Monoid<br>
instances would be symmetric, with no preference for the left argument as<br>
currently.<br>
<br>
<br>
</blockquote>
<br>
Just to throw out an option here: Unbiased. I don't feel strongly about it,<br>
but thought throwing it out may be helpful.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Another question is whether we should take the opportunity of new modules<br>
to modernize and streamline the API a bit. I'd like, at least, to separate<br>
"safe" from "unsafe" functions, putting the unsafe ones in .Unsafe modules.<br>
</blockquote>
<br>
<br>
I think it would be better to keep the API exactly the same, much<br>
like Data.Map.Strict does. I don't want to think about the incidental API<br>
differences when I switch from one module to another. If you're going to<br>
modernize, modernize all the modules at once. That's what version numbers<br>
are for.<br>
</blockquote>
<br>
<br>
+1. I'd also argue against changing the API right now.<br>
<br>
Michael<br>
<br>
______________________________<wbr>_________________<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-bi<wbr>n/mailman/listinfo/libraries</a><br>
<br>
</blockquote></blockquote>
<br>
<br></div></div><span class="HOEnZb"><font color="#888888">
-- <br>
Mario Blazevic<br>
<a href="mailto:mblazevic@stilo.com" target="_blank">mblazevic@stilo.com</a><br>
Stilo International<br>
<br>
This message, including any attachments, is for the sole use of the<br>
intended recipient(s) and may contain confidential and privileged<br>
information. Any unauthorized review, use, disclosure, copying, or<br>
distribution is strictly prohibited. If you are not the intended<br>
recipient(s) please contact the sender by reply email and destroy<br>
all copies of the original message and any attachments.</font></span><div class="HOEnZb"><div class="h5"><br>
______________________________<wbr>_________________<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-bi<wbr>n/mailman/listinfo/libraries</a><br>
</div></div></blockquote></div><br></div>