On 1 May 2016 at 17:00, Herbert Valerio Riedel
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?