Data.IntMap.Strict.findWithDefault is too strict

[Milan Straka]

Hi all,

> Just for reference, here are the two previous threads on library@ about
> the issue. They're well worth the read.
> 
>     http://www.haskell.org/pipermail/libraries/2011-October/016991.html
>     http://www.haskell.org/pipermail/libraries/2011-November/017178.html
> 
> I also want to differ from Johan; from my reading of the threads, the
> issue was settled less conclusively than I would have liked.  In particular,
> extrapolating from the reports of these users, it seems that although
> users do want to know whether or not their thunks are evaluated or not,
> they *only* seem to care about it if the thunk actually is *retained* by
> the data structure.  That is to say, users do *not* usually think of
> maps functions as a way of seq'ing things. And at least in the case
> of findWithDefault, it's trivial to seq the default argument *if* the
> user wanted to.
> 
> I think we can formalize this intuition into a nice reasoning principle
> that admits "more lazy" strict maps.

The current strictness properties are

1. Key and value arguments are evaluated to WHNF;
2. Keys and values are evaluated to WHNF before they are stored in the map.

The simple change that would allow evaluating only the stored keys and
values would be to remove *value arguments* from the point 1, resulting in

1. Key arguments are evaluated to WHNF;
2. Keys and values are evaluated to WHNF before they are stored in the map.

In fact, all keys stored in the map are evaluated (even in
Data.{Map,IntMap}.Lazy), so we could simplify the rule 2. to "Values are
evaluated to WHNF before they are stored in the map", leaving us with

1. Key arguments are evaluated to WHNF;
2. Values are evaluated to WHNF before they are stored in the map.


Note that the point 1. is the same as Data.{Map,IntMap}.Lazy strictness
property, so the Lazy and Strict versions would differ only by inclusion
of point 2.



Is this something users of containers would prefer to the current
properties? If someone thinks so, we could create a separate proposal to
see what do the users wants or if they care.

Cheers,
Milan