deepseq: Add more instances. #50

[David Feuer]

I think you've made an acceptable argument for these instances being
*reasonable*. The question is whether they're more *useful* or more
*confusing*. I'm currently leaning toward confusion. When do you actually
want to `deepSeq` something with references in it? I suppose it could
happen, but it's not likely to come up terribly often, is it?

On Tue, Jan 14, 2020, 7:55 PM Travis Whitaker <pi.boy.travis at gmail.com>
wrote:

> Greetings Haskellers,
>
> I am writing to draw your attention to
> https://github.com/haskell/deepseq/pull/50.
>
> This PR adds NFData instances for UArray, ForeignPtr, and TVar. The
> instances for ForeignPtr and TVar have proven to be somewhat controversial.
> I'll refer to these as "reference types" from here on out, since similar
> concerns have been raised with respect to e.g. IORef. I think the arguments
> presented here apply equally well to IORef.
>
> In summary: the argument against these instances is that rnf forces the
> evaluation of the reference value itself, not the value referred to by the
> reference. This is potentially confusing to NFData users. For example, a
> user might expect that calling force on a TVar value will leave the value
> to which the TVar refers in normal form. If this assumption doesn't hold,
> the user's program will leak thunks.
>
> The argument for these instances is as follows: whether or not a reference
> value is in normal form has nothing to do with whether or not the
> referred-to value is in normal form. For example, consider ForeignPtr.
> ForeignPtr's type constructor argument is just a phantom. Each ForeignPtr
> value is just an Addr# with some finalizers. Whether or not these values
> are in normal form has nothing to do with whether or not the value the
> enclosed address may (or may not!) point to is in normal form. Indeed, an
> NFData instance for ForeignPtr, TVar, or IORef that attempted to force the
> referred-to value would require unsafe IO.
>
> I'm curious to hear other's thoughts about these arguments. I'm hopeful
> that the proposed instances may be added, since I've encountered these
> instances as orphans on numerous occasions.
>
> Thanks for your time,
>
> Travis Whitaker
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200114/e60bed88/attachment.html>