Strictness/laziness warnings

[José Manuel Calderón Trilla]

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 former is pretty complicated I'm working on the latter to avoid
recursive types altogether.

If you're interested, Ralf Hinze's PhD thesis ("Projection-based
Strictness Analysis: Theoretical and Practical Aspects") is my go-to
recommendation for what can be done with strictness analysis,
unfortunately it doesn't solve the problem of strictness over
polymorphic recursion.

If you search for "Generalising the demand analysis to sum types" on
the ghc-devs list the past discussion should come up.

Cheers,

Jose




On Sun, May 29, 2016 at 11:16 PM, David Feuer <david.feuer at gmail.com> wrote:
> 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 the
> first case is not strict in the Int and the second is. I'd also likely
> be interested in a warning about the first case because I'm taking a
> small primitive value (Int) and doing so lazily.
>
> On Sun, May 29, 2016 at 11:04 PM, wren romano <winterkoninkje at gmail.com> wrote:
>> On Sat, May 28, 2016 at 10:14 PM, Edward Kmett <ekmett at gmail.com> wrote:
>>> How would you detect the argument only being forced some of the time? Sounds
>>> like a lot of long-term cross-module book-keeping.
>>
>> Sounds to me like what the strictness analyzer is already doing, ne? I
>> missed the beginning of the thread, so might be off base. If it's more
>> about noticing when the use sites of a given function have some
>> pattern not captured by the strictness determined from the function's
>> definition, then it seems like we shouldn't need /cross/-module
>> bookkeeping: we should be able to just tabulate how each use site's
>> strictness does/doesn't match the interface's spec.
>>
>> --
>> Live well,
>> ~wren
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs