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

[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 <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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/libraries/attachments/20111103/c54eebda/attachment-0001.htm>