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

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 :

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 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@haskell.org http://www.haskell.org/mailman/listinfo/libraries

_______________________________________________ Libraries mailing list Libraries@haskell.org http://www.haskell.org/mailman/listinfo/libraries