A more useful Monoid instance for Data.Map

[Ben Gamari]

Roman Cheplyaka <roma at ro-che.info> writes:

> Great job!
>
> To be fair, there might be code which is not released on hackage (e.g.
> proprietary), but the current instance is so bad that we really should
> take a chance to fix it.
>
> But there's another problem... The "right" instance should really be
> based on Semigroup, not Monoid, but Semigroup is not currently in the
> base. And adding a dependency on semigroups to containers is hardly an
> option.
>
So as I understand it,

  1) There are few packages on Hackage that would break as a result of
     replacing Map's existing Monoid instance.

  2) However, we may want to first cut a release with no Monoid instance
     at all to alert users outside of Hackage of the change in
     semantics. This was suggested for containers-0.6.

  3) Dropping the Monoid instance would hurt current users
     relying only on mempty. Moreover, those who do need a full Monoid
     instance will be forced to define it themselves, incurring two
     breakages (once on removal of the current instance and again on
     reintroduction of the "correct" Monoid instance). This ultimately
     reflects the current problems in refactoring our typeclass
     structure.

  4) As Johan points out in [1], refactoring the typeclass hierarchy is
     currently painful. He says this needs to be fixed before this sort
     of refactoring is attempted.

  5) There are proposals[2] seeking to fix this issue but, as Edward
     points out, it's unclear whether they will adequately solve the
     problem[3]

  6) As a result, the present proposal regarding Map's Monoid instance
     is stuck

Sadly, I can see only a few places where this impass can be broken,

  1) We decide it's not necessary to first drop the Monoid instance this
     is unlikely to affect the current users on Hackage, this could be
     very frustrating for external users. This would obviously need to
     be very well advertised.

  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).

  3) We miraculously resolve the typeclass refactoring problem, allowing
     us to add Semigroup to base, add a Semigroup instance for Map, and
     fix its Monoid instance in one fell swoop

While I agree with hvr that incurring more breakage events than
necessary is not desirable, I nevertheless think we should again
consider option (2) as,

  * Semantic changes like (1) seem too reckless to undertake like this
  
  * The (3) depends upon our ability to rectify deep problems in how
    typeclasses are defined and refactored and will not be solved in the
    near future

We should take advantage of this opportunity to begin an easy cleanup
and accept that there are still other issues that will need to be dealt
with once the tools for doing so exist.

Thoughts?

Cheers,

- Ben


[1] <CAK-tuPaNKkN2Bb5FNc9FaG8-z4OPwDi4WAXP5h0r3Wop_GCQDw at mail.gmail.com>
[2] http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances
[3] <CAJumaK8sp_fYed2t0LabeMYeUyV8ub+u=fM00EoBmv0GD_+OqA at mail.gmail.com>