Proposal: Remove Semigroup and Monoid instances for Data.Map, Data.IntMap, Data.HashMap

[Evan Laforge]

On Wed, Feb 14, 2018 at 6:47 AM, Mario Blažević <mblazevic at stilo.com> wrote:
>         I understand it's hard to grep, but can you guess how many of those
> 40-80 uses of (<>) with the union meaning actually depend on the left-biased
> semantics? I've looked at my code, and it turns out that wherever this
> operation appears, the two maps are guaranteed to have distinct keys.

I know that in a few cases I do explicitly want "left wins", and I do
frequently use (x<>) as a way to accumulate new data.  Sometimes I
expect that new data to override old stuff, sometimes I don't expect
them to overlap, but it's not a problem if they do.  In the cases
where it is a problem (e.g. warn about shadowed names or something), I
have

Util.Map.unique_union :: Ord k =>
    Map.Map k a -> Map.Map k a -> (Map.Map k a, Map.Map k a)
    -- ^ (union, rejected)

I can grep for that: 3 calls, plus 11 more for the version that takes
[(k, a)].  However, in the absence of actual numbers for (<>), don't
take me too seriously.  These kinds of feelings are often shown wrong
by the real numbers.  But even if I could count them, it's not like it
proves anything.  It comes down to style and problem domain.

That said though, is there a way to grep for methods overloaded at a
certain type?  One thing I thought of was recompile Data.Map with a
TypeError instance, but it seems it might be a hassle for a base
package like containers.  Otherwise I imagine you could parse core,
look for resolved methods, and map back to file and line.  Is there a
general purpose core analysis suite out there?

>         There is actually one use I'm not sure about, I'll have to make sure
> there's no bug hiding there. That is one reason I'm supporting the proposal,
> by the way: the existing behaviour that silently drops values is much more
> likely to cause bugs.

It's true it does, but since I think of (<>) as union, and union does
that too, it doesn't surprise me.  Actually the surprising thing was
that Map.union is left-biased, while it seems like most languages go
the other way.  But that was just a general haskell oddity that I
accustomed myself to many years ago.