<div dir="ltr"><div>"inNeeFable", i love this pun too much :) <br></div><div>cf <a href="https://www.merriam-webster.com/dictionary/ineffable">https://www.merriam-webster.com/dictionary/ineffable</a></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 7, 2020 at 1:59 PM Carter Schonwald <<a href="mailto:carter.schonwald@gmail.com">carter.schonwald@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">aka, we shouldn't provide instances for stuff thats not "NF'able", so that these tricky bits aren't invisible, right?<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 15, 2020 at 8:37 PM Evan Laforge <<a href="mailto:qdunkan@gmail.com" target="_blank">qdunkan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">As I understand, the case for against is: I have a space leak, I'll try rnf on this data. Space leak is still present, so it must not be due to that data, so I go to the next idea.  But if there's something in there that rnf silently skipped, then I'll be misled.  It would be nice if the compiler will warn me where the possibly leaking bits that rnf can't help with, which is presumably closures and explicit pointers.</div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 15, 2020, 3:43 AM Andrew Martin <<a href="mailto:andrew.thaddeus@gmail.com" target="_blank">andrew.thaddeus@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div>My understanding of the argument for and against is:</div><div><br></div><div>* For: Typeclass instances should be provided for as many types as possible, and IORef, TVar, etc. only admit a single way to define NFData</div><div>* Against: Intuitively, NFData means that data is plain old sums and products all the way down, all of which can be forced. This would mean that anything with an NFData instance should be able to go into a compact region (except that pinned byte arrays, and consequently bytestrings, cannot)</div></div><div dir="ltr"><br></div><div>I'm inclined to agree with most of the opinions expressed earlier on the thread. That is, given how minor the convenience is, the confusion is probably not worth the convenience. I'll think about this more today.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jan 14, 2020 at 7:55 PM Travis Whitaker <<a href="mailto:pi.boy.travis@gmail.com" rel="noreferrer" target="_blank">pi.boy.travis@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);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" rel="noreferrer" target="_blank">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" rel="noreferrer" target="_blank">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><br clear="all"><br>-- <br><div dir="ltr">-Andrew Thaddeus Martin</div></div>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" rel="noreferrer" target="_blank">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>
_______________________________________________<br>
Libraries mailing list<br>
<a href="mailto:Libraries@haskell.org" target="_blank">Libraries@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries</a><br>
</blockquote></div>
</blockquote></div>