<div dir="ltr"><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:16px;font-style:normal;font-variant-ligatures:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;background-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-color:initial;float:none;display:inline">I am strongly in favour of this as well. I do not like the newtype approach, I think backwards-*incompatibility* with four to five year-old (or two to three year-old) code is OK.</span><br></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 13, 2018 at 3:04 PM, Daniel Cartwright <span dir="ltr"><<a href="mailto:chessai1996@gmail.com" target="_blank">chessai1996@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">I am strongly in favour of this as well. I do not like the newtype approach, I think backwards-*incompatibility* with four to five year-old (or two to three year-old) code is OK.</div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 13, 2018 at 2:59 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">I don't think the old proposal was really the right way.<br>
<div class="m_-390705486629878266HOEnZb"><div class="m_-390705486629878266h5"><br>
On Tue, Feb 13, 2018 at 2:54 PM, Mario Blažević <<a href="mailto:mblazevic@stilo.com" target="_blank">mblazevic@stilo.com</a>> wrote:<br>
> +1. But whatever happened to your proposal from last May? I don't think<br>
> there were any objections to it. Would the two proposals be combined, or<br>
> have you decided to drop the previous one?<br>
><br>
> <a href="https://mail.haskell.org/pipermail/libraries/2017-May/028036.html" rel="noreferrer" target="_blank">https://mail.haskell.org/piper<wbr>mail/libraries/2017-May/028036<wbr>.html</a><br>
><br>
> On 2017-05-25 12:55 PM, David Feuer wrote:<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*<br>
>> for the new modules. I can't think of any, so I'm reaching out to the<br>
>> list. Please suggest names! Another question is whether we should take<br>
>> the opportunity of new modules to modernize and streamline the API a<br>
>> bit. I'd like, at least, to separate "safe" from "unsafe" functions,<br>
>> putting the unsafe ones in .Unsafe modules.<br>
><br>
><br>
><br>
> On 2018-02-13 02:33 PM, David Feuer wrote:<br>
>><br>
>> Many people have recognized for years that the Semigroup and Monoid<br>
>> instances for Data.Map, Data.IntMap, and Data.HashMap are not so<br>
>> great. In particular, when the same key is present in both maps, they<br>
>> simply use the value from the first argument, ignoring the other one.<br>
>> This somewhat counter-intuitive behavior can lead to bugs. See, for<br>
>> example, the discussion in Tim Humphries's blog post[*]. I would like<br>
>> do do the following:<br>
>><br>
>> 1. Deprecate the Semigroup and Monoid instances for Data.Map.Map,<br>
>> Data.IntMap.IntMap, and Data.HashMap.HashMap in the next releases of<br>
>> containers and unordered-containers.<br>
>><br>
>> 2. Remove the deprecated instances.<br>
>><br>
>> 3. After another several years (four or five, perhaps?), make a major<br>
>> release of each package in which the instances are replaced with the<br>
>> following:<br>
>><br>
>>    instance (Ord k, Semigroup v) => Semigroup (Map k v) where<br>
>>      (<>) = Data.Map.Strict.unionWith (<>)<br>
>>    instance (Ord k, Semigroup v) => Monoid (Map k v) where<br>
>>      mempty = Data.Map.Strict.empty<br>
>><br>
>>    instance Semigroup v => Semigroup (IntMap v) where<br>
>>      (<>) = Data.IntMap.Strict.unionWith (<>)<br>
>>    instance Semigroup v => Monoid (IntMap v) where<br>
>>      mempty = Data.IntMap.Strict.empty<br>
>><br>
>>    instance (Eq k, Hashable k, Semigroup v) => Semigroup (HashMap k v)<br>
>> where<br>
>>      (<>) = Data.HashMap.Strict.unionWith (<>)<br>
>>    instance (Eq k, Hashable k, Semigroup v) => Monoid(HashMap k v) where<br>
>>      mempty = Data.HashMap.Strict.empty<br>
>><br>
>> Why do I want the strict versions? That choice may seem a bit<br>
>> surprising, since the data structures are lazy. But the lazy versions<br>
>> really like to leak memory, making them unsuitable for most practical<br>
>> purposes.<br>
>><br>
>> The big risk:<br>
>><br>
>> Someone using old code or old tutorial documentation could get subtly<br>
>> wrong behavior without noticing. That is why I have specified an<br>
>> extended period between removing the current instances and adding the<br>
>> desired ones.<br>
>><br>
>> Alternatives:<br>
>><br>
>> 1. Remove the instances but don't add the new ones. I fear this may<br>
>> lead others to write their own orphan instances, which may not even<br>
>> all do the same thing.<br>
>><br>
>> 2. Write separate modules with newtype-wrapped versions of the data<br>
>> structures implementing the desired instances. Unfortunately, this<br>
>> would be annoying to maintain, and also annoying to use--packages<br>
>> using the unwrapped and wrapped versions will use different types.<br>
>> Manually wrapping and unwrapping to make the different types work with<br>
>> each other will introduce lots of potential for mistakes and<br>
>> confusion.<br>
>><br>
>> Discussion period: three weeks.<br>
>><br>
>> [*] <a href="http://teh.id.au/posts/2017/03/03/map-merge/index.html" rel="noreferrer" target="_blank">http://teh.id.au/posts/2017/03<wbr>/03/map-merge/index.html</a><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>
><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>
______________________________<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>
</div></div></blockquote></div><br></div>