deepseq: instance NFData (a -> b)

[Boespflug, Mathieu]

On 1 May 2016 at 17:00, Herbert Valerio Riedel <hvriedel at gmail.com> wrote:
> On 2016-05-01 at 16:51:45 +0200, Boespflug, Mathieu wrote:
>
> [...]
>
>> This instance doesn't make much sense (to me at least) and is pretty
>> problematic for apps that use NFData constraints as evidence that
>> values are ground and fully evaluated (hence don't capture arbitrary
>> resources). In HaskellR we use NFData constraints to make sure only
>> fully evaluated ground data escapes the scope of a region. But
>> functions are not a first-order values. They can leak arbitrary
>> resources out of the scope of a region.
>
> Are the recently added NFData instances for IORef/MVar problematic as
> well?

I guess so, yes!

These 3 instances, along with the STRef one, strike me as antithetical
to the purpose stated at the top of the DeepSeq module:

"A typical use is to prevent resource leaks in lazy IO programs,
[...]. Another common use is to ensure any exceptions hidden within
lazy fields of a data structure do not leak outside the scope of the
exception handler, or to force evaluation of a data structure in one
thread, before passing to another thread (preventing work moving to
the wrong threads)."

Or perhaps - we should at the very clarify and characterize precisely
what invariants NFData instances are or are not expected to enforce?