#1460: Problem with Monoid instance of Data.Map -------------------------------------+------------------------------------- Reporter: ahey@… | Owner: (none) Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.6.1 Resolution: fixed | Keywords: Data.Map | Monoid Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by bgamari): I agree that a monoidal-combining `Map` is much nicer than our current `Map` (and usually what I find I need); I have been a proponent of this change in the past and even maintain the `monoidal-containers` library wrapping `containers` with these semantics. However, my impression is that argument (1) mentioned in comment:8 alone is enough to sink this proposal in many people's minds. In fact, with a few years of experience behind me since last looking at this, I may even agree. I don't think it is realistic to expect that we will be able to easily discern broken packages in a large scale study; breakage due to semantic changes like this can be very hard to spot. In the best case you have a use-site where the value type has no `Semigroup` instance, in which case the change will elicit a compile-time error. However, in the case where you do have an instance on-hand you will see silent breakage, which may or may not be evident in the runtime behavior of the program or test failures. Moreover, with the ubiquity of packages with lax handling of upper bounds will likely make managing such a change challenging, even if breakage can be readily identified; even a super-major version bump will have no effect on a package that has no bounds at all. Unfortunately, I suspect the only way we can make this change happen is via the introduction of new interfaces and not changing those that we already have. This may be via continuing to use `monoidal-containers` and others (e.g. `reducers`), although I admit that this isn't a terribly great option. Perhaps we could discuss merging a wrapper like `monoidal- containers` into `containers` (and, perhaps, `unordered-containers`). The good news is that with Backpack we are now slightly better equipped to provide such parallel interfaces; unfortunately it will likely be several years before we can rely on Backpack for a critical package like `containers`. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/1460#comment:10 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler