Strictness/laziness warnings

[Edward Kmett]

I have code that'd trip at least 2&3 in use in production. #2 arises for
some tricks that Wren first introduced me to for loop invariant code
motion. #3 arises when you want to memoize a result but only produce it
lazily in case it isn't used. I don't quite understand what you mean by
"conditionally strict" in an argument though.

-Edward

On Sat, May 28, 2016 at 8:00 PM, David Feuer <david.feuer at gmail.com> wrote:

> There are certain patterns of strictness or laziness that signal the need
> for extra caution. I'm wondering whether it might be possible to offer
> warnings for different varieties of them, and pragmas suppressing the
> warnings at the relevant sites. Some function behaviors that suggest extra
> care:
>
> 1. Conditionally strict in an argument. In many cases, making it
> unconditionally strict will improve performance.
> 2. Strict in an argument that is or could be a function or a newtype
> wrapper around a function. This can be caused by  adding too much
> strictness defensively or to plug a leak.
> 3. Lazy in a primitive argument like an Int. This could lead to
> unnecessary boxing.
>
> Any of these could occur in correct, efficient code. But I'd love to be
> presented a list of warnings to check over, and a way to check items off
> the list with pragmas.
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20160528/17c9aa2b/attachment-0001.html>