Re: Data.IntMap.Strict.findWithDefault is too strict

Hey 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. Cheers, Edward Excerpts from Johan Tibell's message of Thu Dec 13 08:04:09 -0800 2012:

Hi,

On Thu, Dec 13, 2012 at 7:49 AM, Ben Gamari wrote:

...

Christian Maeder writes:

...

when trying out Data.IntMap.Strict instead of Data.IntMap, I've noticed (after some confusion) that Data.IntMap.Strict.findWithDefault evaluates the default value, even if it is not used!

I usually pass an error-call to IntMap.findWithDefault to get a more informative crash-message than by using IntMap.!

I have also found this to be problematic in the past. Is there a compelling reason to keep the current behavior? I would find this function far more useful if the default value were lazily evaluated.

The behavior is at least documented. From Data.IntMap.Strict:

"This module satisfies the following strictness properties:

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

We agonized over this choice when we made it. The reasoning for the current behavior is that these strictness properties help you reason about whether values passed to the API are evaluated or not, as that no longer depend on the contents of them map. We're not really looking to support passing undefined values in the API.

-- Johan