<div dir="ltr">How would you detect the argument only being forced some of the time? Sounds like a lot of long-term cross-module book-keeping.<div><br></div><div>-Edward</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, May 28, 2016 at 10:02 PM, David Feuer <span dir="ltr"><<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">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.</p><div class="HOEnZb"><div class="h5">
<div class="gmail_quote">On May 28, 2016 9:16 PM, "Edward Kmett" <<a href="mailto:ekmett@gmail.com" target="_blank">ekmett@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">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.<div><br></div><div>-Edward</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, May 28, 2016 at 8:00 PM, David Feuer <span dir="ltr"><<a href="mailto:david.feuer@gmail.com" target="_blank">david.feuer@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">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:</p>
<p dir="ltr">1. Conditionally strict in an argument. In many cases, making it unconditionally strict will improve performance.<br>
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.<br>
3. Lazy in a primitive argument like an Int. This could lead to unnecessary boxing.</p>
<p dir="ltr">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.</p>
<br>_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
<br></blockquote></div><br></div>
</blockquote></div>
</div></div></blockquote></div><br></div>