This is strictness over sum types. Ömer and I worked on adding it to a
fork of GHC.
It's definitely possible, the main complications are how to deal with
recursive types in the presence of polymorphic recursion and how to
detect recursive types in the presence of higher-kinded types. Because
the f
Mostly I'm looking for a rough estimate. Some false positives and
false negatives are tolerable. If I have something like
f :: Int -> Maybe String -> String
f _ Nothing = "Hi there!"
f n (Just b) = if n > 0 then show b else "whatever"
then I'd likely be interested in a warning about the fact that
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 wrote:
> I'm not suggesting these things are *wrong*, and I wouldn't want the
> warnings to be included in -Wall.
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" wrote:
> I have code that
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
"conditionall
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.
