deepseq: Add more instances. #50

[Elliot Cameron]

And similar to Show, many of us wish there was a *different *class that was
mostly for debugging, not for serialization. If there's a perception that
"NFData" means "able to be put in a compact region" then we definitely
don't want these instances. But perhaps what we want is two classes with
different guarantees.

On Wed, Jan 15, 2020 at 10:40 AM Elliot Cameron <eacameron at gmail.com> wrote:

> As long as "Show" is the "other side of Read", a Show instance for
> reference types is completely silly. NFData doesn't have *that* complication
> at least.
>
> On Wed, Jan 15, 2020 at 6: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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200115/acca27d0/attachment.html>