RFC: Should Data.IntMap.Strict be value-strict in the function arguments or the map itself

Gracjan Polak gracjanpolak at gmail.com
Mon Oct 31 15:35:11 CET 2011

Johan Tibell <johan.tibell <at> gmail.com> writes:
> There are two subtly different ways these APIs can be strict:
> 1. All the functions are strict in the value argument, or
> 2. The structure is strict in the value field.

The problem that should be addressed by strict API is accumulation of
unevaluated thunks that user of the API has no control over.

Therefore strict API should solve stack-overflow issues and memory leaks.

Taking that thought further...

> The difference shows up in functions like insertWith. For example, given
>     insertWith (\ old _new -> old + 1) k v someMap
> should 'v' be evaluated is the key 'k' is already in the map.

Here user has the control of thunks by, for example, doing:

>     insertWith (\ old new -> new `seq` (old + 1)) k v someMap

So the user has full control if v should be evaluated or not.

There is no need to force v always and seems limiting application scenarios.

> If we go with option 2 it is more difficult for the user to reason about 
> if a given value passed to the API is evaluated or not...

Which IMHO is not a problem. For me always problem was the data that was already
in the Map, but in unevaluated form.

I vote for option 2 as it is the minimal option that solves my problem.

(I have no comments about keys)


More information about the Libraries mailing list