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

[Simon Meier]

I also prefer the fully strict version. From an application programmer
perspective, it makes the following reasoning valid:

If my Map is in WHNF, then all computations that it depends on have
been performed.

This makes hunting for space leaks a LOT easier in my opinion. This
options also allows applications like stateful servers to easily
extend the full strictness to their whole state, such that WHNF on
their state implies that there are no dangling computations left. I
imagine that, in many cases, this is a good implementation decision
for such applications.

best regards,
Simon

2011/11/3 Edward Kmett <ekmett at gmail.com>:
> I've finally come around to liking the slightly stricter implementation. If
> someone _really_ needs the slightly lazy version they can usually check to
> see if the map is null by hand, before calling in to the library, but in the
> converse situation, you can't tell ghc "no, really, that argument has
> already been seq'd so don't bother."
> Now I have to hunt for this behavior in my _own_ libraries. Blech.
> -Edward
>
> On Thu, Nov 3, 2011 at 3:43 PM, Johan Tibell <johan.tibell at gmail.com> wrote:
>>
>> Hi all,
>>
>> After thinking about this some more I think we should go with option one
>> (the most strict one). My arguments in favor are that
>>
>>  * it's easier to explain and remember,
>>  * it's harder to be too lazy by mistake*,
>>  * Simon M thinks it'll help GHC to avoid some redundant seq:s, and
>>  * if we can specialize the structure in the future to use monomorphic
>> representations we can pass the value unboxed.
>>
>> Milan, what are your current thoughts?
>>
>> * It's easier to be too lazy by mistake if there are a few functions that
>> are less strict than the remaining ones.
>>
>> Cheers,
>> Johan
>>
>>
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://www.haskell.org/mailman/listinfo/libraries
>>
>
>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://www.haskell.org/mailman/listinfo/libraries
>
>