[GHC] #1460: Problem with Monoid instance of Data.Map

[GHC]

#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