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
