A more useful Monoid instance for Data.Map
bgamari.foss at gmail.com
Tue Mar 12 16:06:22 CET 2013
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
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
4) As Johan points out in , 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 seeking to fix this issue but, as Edward
points out, it's unclear whether they will adequately solve the
6) As a result, the present proposal regarding Map's Monoid instance
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
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.
 <CAK-tuPaNKkN2Bb5FNc9FaG8-z4OPwDi4WAXP5h0r3Wop_GCQDw at mail.gmail.com>
 <CAJumaK8sp_fYed2t0LabeMYeUyV8ub+u=fM00EoBmv0GD_+OqA at mail.gmail.com>
More information about the Libraries