Too restrictive type signatures

[Vlix]

I feel that at least the following functions should have less restrictive type signatures:
C) {current signature}
P) {proposed signature}

C) insertWith :: Ord k => (a -> a -> a) -> k -> a -> Map k a -> Map k a
P) insertWith :: Ord k => (a -> b -> b) -> k -> a -> Map k b -> Map k b
---
C) insertWithKey :: Ord k => (k -> a -> a -> a) -> k -> a -> Map k a -> Map k a
P) insertWithKey :: Ord k => (k -> a -> b -> b) -> k -> a -> Map k b -> Map k b
---
C) insertLookupWithKey :: Ord k => (k -> a -> a -> a) -> k -> a -> Map k a -> (Maybe a, Map k a)
P) insertLookupWithKey :: Ord k => (k -> a -> b -> b) -> k -> a -> Map k b -> (Maybe b, Map k b)

[treeowl]

While I agree the signatures are unfortunate, your proposed replacements simply won't work. Can you understand why? Try implementing them using insert and lookup.

[Vlix]

Ah, I've overlooked the case where it's just an insert instead of an "update".

Then I feel like another set of functions that "upsert" (update/insert) would be helpful. e.g.:
upsert :: Ord k => b -> (a -> b -> b) -> k -> a -> Map k b -> Map k b
upsert x f key newVal mp = ...
which would insert k x in case the key was absent and
insert k (f newVal oldVal)
in case the key already exists.

upsert :: Ord k => a -> (b -> a -> a) -> k -> b -> Map k a -> Map k a
upsert = go
  where
    go :: Ord k => a -> (b -> a -> a) -> k -> b -> Map k a -> Map k a
    go a _ !kx _ Tip = singleton kx a
    go a f !kx x (Bin sy ky y l r) =
        case compare kx ky of
            LT -> balanceL ky y (go a f kx x l) r
            GT -> balanceR ky y l (go a f kx x r)
            EQ -> Bin sy kx (f x y) l r

[treeowl]

I've been thinking the natural options are

whatever :: Ord k => b -> (b -> b) -> k -> Map k b -> Map k b
whatever' :: Ord k => (Maybe b -> b) -> k -> Map k b -> Map k b

[sjakobi]

Is there anything that ought to be addressed in this issue? Currently I'm a bit confused.

[treeowl]

@sjakobi, I think this is really just another instance of people complaining about how wretched the insertWith type is. Let's have a little conference and decide what to suggest to the libraries list. It's been long enough; time to bite the bullet and fix this mess.

[sjakobi]

@sjakobi, I think this is really just another instance of people complaining about how wretched the insertWith type is.

I actually wasn't aware that insertWith itself is so problematic. You have to know which value comes first in the parameters of the combining function, but that's about it, no?! For a bit more safety, people can use alter.

whatever' :: Ord k => (Maybe b -> b) -> k -> Map k b -> Map k b

I do like this type though. Maybe we should give the implementation in the documentation for alter (and reference it from insertWith)?!

I'm not opposed to exporting it either.

---

The issue of fromListWith (#333, haskell-unordered-containers/unordered-containers#264) is more grave IMHO since the behaviour is so counterintuitive. That it internally uses insertWith seems like an implementation detail to me though.

[treeowl]

Personally, I have to look up the insertWith documentation every single time I want to use it.

[sjakobi]

OK. I guess we can't change or get rid of insertWith though.

Is using alter directly good enough?

Otherwise we need a proposal for an addition – possibly with the mentioned Ord k => (Maybe b -> b) -> k -> Map k b -> Map k b type.