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" <ekm...@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.fe...@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@haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> >> >
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs