<div dir="ltr">I tend to avoid Map.union and the other biased combining functions, simply because they seem a bit too easy for someone to accidentally come along later and exchange the order by accident.  On the other hand, having Map.insert use a Monoid instance seems like it would be quite unwieldy.</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 25, 2017 at 4:37 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"><div>That's a really good question, and could theoretically even generalize more than that: should `insert` have a `Monoid` or `Semigroup` constraint on the key as well? Should this API explicitly avoid any form of throwing away values, and insist that, if that's the behavior you want, you do something like `insertWith const`?<br><br></div>I think my guess is in line with yours, that the rest of the API functions should continue with the discard behavior of the current API, but it's worth at least raising the question.<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Thu, May 25, 2017 at 2:08 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">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>
<span class="m_5376092631521391659im m_5376092631521391659HOEnZb"><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>
><br>
><br>
</span><div class="m_5376092631521391659HOEnZb"><div class="m_5376092631521391659h5">> 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>
>><br>
>> On 2017-05-25 12:55 PM, David Feuer wrote:<br>
>>><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>
>><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>
><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>
>>><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>
>><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>
><br>
><br>
> +1. I'd also argue against changing the API right now.<br>
><br>
> Michael<br>
><br>
</div></div><div class="m_5376092631521391659HOEnZb"><div class="m_5376092631521391659h5">> ______________________________<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>
</div></div></blockquote></div><br></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>