Strictness/laziness warnings

David Feuer david.feuer at
Sun May 29 02:02:32 UTC 2016

I'm not suggesting these things are *wrong*, and I wouldn't want the
warnings to be included in -Wall. They're just possible areas of concern.
By "conditionally strict" I mean that the argument in question is only
forced sometimes.
On May 28, 2016 9:16 PM, "Edward Kmett" <ekmett at> wrote:

> 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>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the ghc-devs mailing list