Re: A more useful Monoid instance for Data.Map

12 Mar 2013

      Johan Tibell  writes:
...
On Tue, Mar 12, 2013 at 8:06 AM, Ben Gamari  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] 