deepseq: instance NFData (a -> b)

[Boespflug, Mathieu]

+1

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.
--
Mathieu Boespflug
Founder at http://tweag.io.


On 1 May 2016 at 16:38, Henning Thielemann
<lemming at henning-thielemann.de> wrote:
>
> According to Haddock comments, between deepseq-1.2 and deepseq-1.3 an
> instance for NFData on functions was introduced without previous discussion.
> I find this instance pretty problematic since it has no superclasses. The
> correct instance would be certainly something like
>
> instance (Enumerate a, NFData b) => NFData (a -> b)
>
> where Enumerate would be a new class that allows to enumerate all values of
> a type. This would be hardly useful because it is pretty inefficient. I'd
> prefer that the instance is removed, again, or even better, be replaced by a
> non-implementable instance. Alternatively we should replace it by a correct
> implementation with corresponding superclasses. If we do the second, then we
> could still omit the Enumerate instance for types where enumeration of all
> values of the type is too expensive.
>
> I assume that the instance was added to simplify automatic derivation of
> NFData instances. However, I think it would be better if people insert
> custom deepseq implementation for the expected functions then.
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries