deepseq: Add more instances. #50

[Carter Schonwald]

"inNeeFable", i love this pun too much :)
cf https://www.merriam-webster.com/dictionary/ineffable

On Fri, Feb 7, 2020 at 1:59 PM Carter Schonwald <carter.schonwald at gmail.com>
wrote:

> aka, we shouldn't provide instances for stuff thats not "NF'able", so that
> these tricky bits aren't invisible, right?
>
> On Wed, Jan 15, 2020 at 8:37 PM Evan Laforge <qdunkan at gmail.com> wrote:
>
>> 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.
>>
>> On Wed, Jan 15, 2020, 3:43 AM Andrew Martin <andrew.thaddeus at gmail.com>
>> wrote:
>>
>>> My understanding of the argument for and against is:
>>>
>>> * For: Typeclass instances should be provided for as many types as
>>> possible, and IORef, TVar, etc. only admit a single way to define NFData
>>> * 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)
>>>
>>> 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.
>>>
>>> On Tue, Jan 14, 2020 at 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
>>>>
>>>
>>>
>>> --
>>> -Andrew Thaddeus Martin
>>> _______________________________________________
>>> Libraries mailing list
>>> Libraries at haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>>
>> _______________________________________________
>> 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/20200207/cfb5ac65/attachment.html>