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 <[email protected]> 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" <[email protected]> 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 <[email protected]> >> 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 >>> [email protected] >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >>> >>
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
