Need principled approach to strictness properties in Data.Map.Strict
fox at ucw.cz
Sat Nov 19 14:52:21 CET 2011
> 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
> 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).
More information about the Libraries