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