Need principled approach to strictness properties in Data.Map.Strict

[Milan Straka]

Hi all,

> After trying to document the strictness properties of the new
> Data.Map.Strict module, which is meant to provides a value strict
> version of the Data.Map API, I feel less sure about our prior decision
> to make all functions strict in value arguments (even though I was the
> main proponent).
> 
> The documentation I ended up with in Data.Map.Strict was:
> 
>     Strictness properties
>     =====================
> 
>     This module satisfies the following strictness properties:
> 
>      1. Key and value arguments are evaluated to WHNF;
> 
>      2. Keys and values are evaluated to WHNF before they are stored in
>      the map.
> 
>     Here are some examples that illustrate the first property:
> 
>         insertWith (\ old new -> old) k undefined m == undefined
>         delete undefined m == undefined
> 
>     Here are some examples that illustrate the second property:
> 
>         map (\ v -> undefined) m == undefined -- m is not empty
>         mapKeys (\ k -> undefined) m == undefined -- m is not empty
> 
> More than one person said the distinction between (1) and (2) isn't
> clear and someone else felt that the extra (1) is unnecessary (for
> values).
> 
> We definitely want (2): it's the property that ensures that the map
> never contains any thunks (if we also guarantee that the map is also
> spine strict). This property eliminates the space leaks that people
> sometimes run into. This property is the raison d'etre for the
> Data.Map.Strict module.
> 
> I would like to settle the strictness properties of Data.Map.Strict
> once and for all. I would prefer to find a principled reason for the
> resulting decision or, if I can't have that, I want to lay out all the
> pros and cons and then make a decision. I think this issue is
> important, as we're likely to see more modules that help the users get
> a hold on evaluation order in the future.

The only "benefit" of _not_ having (1) is that in some corner cases
the value is not evaluated (i.e., delete from an empty map).
I fail to see any advantage in this.

The benefits of having (1) are (as Johan wrote)
- simple rule for the users of the API
- possible performance wins (probably minor)

So for me, adding (1) has advantages and no disadvantages.
I vote for including (1).

Cheers,
Milan