A more useful Monoid instance for Data.Map

[wren ng thornton]

On 4/27/12 9:04 PM, Daniel Peebles wrote:
> Hi all,
>
> Currently Data.Map has a Monoid instance, but it's rather lossy and not as
> general as it could be:
>
> instance (Ord k) =>  Monoid (Map k v) where
 >    mempty  = empty
>    mappend = union
>    mconcat = unions
>
> The instance would be much nicer if it required a Monoid on v and used
> unionWith mappend instead of just union.

I'm inclined to agree as well.

> I realize that changing instances could break code, but I'd be curious
> to see how many people even use the current monoid instance. Does
> anyone have any system for testing hypotheses like this (by
> typechecking a large randomized chunk of hackage or something)?

The thing I'd be more worried about is silent changes to semantics. At 
least if it doesn't typecheck then you know something went wrong; but 
there are lots of monoids and so it's very likely to typecheck but to 
alter semantics.

When I've been curious about things like this before, I've just used 
grep on my local copy of Hackage. But that only works for things with 
relatively unique names; it'd be completely unhelpful for something 
type-directed like this.

You could try removing the instance entirely and then see how much of 
Hackage you can get to compile. That way you'll detect all uses, not 
just the uses for non-monoidal value types. You should be able to get 
your hands on one of the build-all-of-Hackage scripts people've used for 
this sort of thing in the past.

-- 
Live well,
~wren