A more useful Monoid instance for Data.Map

[Ben Gamari]

Johan Tibell <johan.tibell at gmail.com> writes:

> On Tue, Mar 12, 2013 at 8:06 AM, Ben Gamari <bgamari.foss at gmail.com> wrote:
>
>>   2) We decide it is acceptable to break users code multiple times, drop
>>      the Monoid instance and reintroduce the new instance after some
>>      delay. The length of this delay could range from no delay at all
>>      (allowing folks to quickly move to the new instance, although
>>      potentially unwittingly) to several months (hoping that most users
>>      will realize the change during this window).
>>
>
> Before we even consider breaking user code we should see how much code will
> be broken. If someone with spare cycles could download a copy of Hackage
> and grep for uses of mappend on Data.Map that would be great.

It seems like Christian did a pretty good approximation to this[1] in January, no?

     After removing the Monoid instance for Map and IntMap, each reverse
     dependency of containers was separately compiled under a standard setup of
     GHC 7.6.1 in order to avoid shared dependency problems. Out of 1440 reverse
     dependencies, I could get 545 to compile. However, only the following
     packages fail because of Monoid instance issues:

     - caledon
     - data-default
     - dom-lt
     - EnumMap
     - i18n
     - semigroups
     - unamb-custom
     - vacuum
     - stringtable-atom

Given that the Monoid instance is completely gone in this test, this
list should be a superset of the packages that will break due to the
semantic change.

Cheers,

- Ben


[1] <CALCpNBpcmEfG1moxX=CbHOS2LwNGeLEFbTyyfteJYPwMoLR9SQ at mail.gmail.com>