<div dir="auto">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?</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 14, 2020, 7:55 PM Travis Whitaker <<a href="mailto:pi.boy.travis@gmail.com">pi.boy.travis@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr">Greetings Haskellers,<div><br></div><div>I am writing to draw your attention to <a href="https://github.com/haskell/deepseq/pull/50" target="_blank" rel="noreferrer">https://github.com/haskell/deepseq/pull/50</a>.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Thanks for your time,</div><div><br></div><div>Travis Whitaker</div></div></div></div></div></div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank" rel="noreferrer">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>