Roman Cheplyaka <roma@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@mail.gmail.com> [2] http://hackage.haskell.org/trac/ghc/wiki/DefaultSuperclassInstances [3] <CAJumaK8sp_fYed2t0LabeMYeUyV8ub+u=fM00EoBmv0GD_+OqA@mail.gmail.com>