Strictness/laziness warnings

[Edward Kmett]

How would you detect the argument only being forced some of the time?
Sounds like a lot of long-term cross-module book-keeping.

-Edward

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

> 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 gmail.com> 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 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/8526f5de/attachment.html>