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

[Bardur Arantsson]

On 11/19/2011 12:03 AM, Johan Tibell wrote:
> Hi all,
>
[--snip--]

Let me just preface this by saying that I'm definitely no expert on 
laziness/strictness in Haskell-land. Having followed the mailing lists 
for a few years, I definitely agree that this area is something which 
desperately needs attention from a practical point of view. (It seems 
there's a Monad.State.Strict thread every few months, etc.)

So, FWIW:

> More than one person said the distinction between (1) and (2) isn't
> clear

Does it really matter? AFAICT, the most important thing is that the use 
of the API doesn't lead to surprising behavior, aka. the principle of 
least astonishment (POLA).

[--snip--]

> Without the extra strictness there are degenerate cases that can
> catch people off guard. For example,
>
>      insertWith (\ old new ->  if old == maxValue then old else new + 1) k v m
>
> is lazy in 'v' because there's a rare case (old == maxValue) where
> 'new' isn't evaluated.

For me, this behavior would really violate the POLA.

If I'm passing something to an API which "is strict" (as indicated by 
Data.Map.Strict), then I'd certainly expect everything I pass in to be 
evaluated.

[--snip--]

Are there any specific and serious disadvantes to including (1)? It 
might be useful to have a concise list for reference. (Sorry, I didn't 
follow the other thread closely.)

-- 
Bardur Arantsson