<div dir="ltr">Given that we're talking about a years-long process, what about using the newtype approach as an intermediate step, so that we don't get additional proliferation of third-party newtype wrappers in the interim? Deprecate the current instances and add instances using newtype wrappers at the same type, such that a newtype'd version of the current functionality is available to folks as a migration path, as well as a newtype for which the instances provide the correct behavior. Then, in the future, the newtypes for the corrected behavior will eventually become superfluous, and for those who rely on the newtypes that represent the current behavior, they won't have to change anything.</div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Feb 13, 2018 at 1:07 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"><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><div class="h5"><div class="m_-8486516578295966489HOEnZb"><div class="m_-8486516578295966489h5"><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_-8486516578295966489m_-390705486629878266HOEnZb"><div class="m_-8486516578295966489m_-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></div></div></blockquote></div><br></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>