RFC: Should Data.IntMap.Strict be value-strict in the function arguments or the map itself

[Milan Straka]

Hi,

> As discussed in an earlier (accepted) proposal we're adding
> Data.[Int]Map.{Strict,Lazy} APIs to make it easier for users to get the
> desired strictness.
> 
> There are two subtly different ways these APIs can be strict:
> 
> 1. All the functions are strict in the value argument, or
> 2. The structure is strict in the value field.
> 
> The difference shows up in functions like insertWith. For example, given
> 
>     insertWith (\ old _new -> old + 1) k v someMap
> 
> should 'v' be evaluated is the key 'k' is already in the map. (Note that the
> value isn't used in the update function.)
> 
> If we go with option 2 it is more difficult for the user to reason about if
> a given value passed to the API is evaluated or not (as in the above
> example). We currently use option 1 for keys i.e.
> 
>     insert k v someMap
> 
> is strict in the key even if the map is empty (which wouldn't require us to
> look at the key).
> 
> Thoughts? I'd love to see some design pros/cons of both approaches.

At first I thought there would be performance gain in 1., as the value
could be passed unboxed. But now I believe it is not true -- the value
type is never specialized as it is stored as a generic type all the
time.

Without the performance bias, the possibility 2. seems fine.

BTW, 1. does not fully specify the behaviour -- for example, does
  insertWith' f k v map
forces the result of (f old new) when the key is already present?
Possibility 2. says 'yes', possibility 1. does not say anything.
Maybe the 1. should be "the structure is strict in the value field
and also all the functions are strict in the value argument".

Although my opinion was different just a while ago, I am now slightly
in favor of 2.

Cheers,
Milan