deepseq: Add more instances. #50

[David Feuer]

No one is thankful for the Foldable instance of tuples as far as I know.
Many of us tolerate it because we want the Traversable instance. But yes,
you make a point about Criterion. I hadn't considered that application.

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

> Thanks for your email, David.
>
> The NFData class is an important part of a large number of APIs on
> Hackage. According to https://packdeps.haskellers.com/reverse, the
> deepseq package has over 1,200 dependent packages. In my own case, I work
> with a lot of record types with ForeignPtr fields. If I want to, say, use
> one of these types as part of a Criterion environment for a benchmark, I
> will need an NFData instance (
> https://hackage.haskell.org/package/criterion-1.5.6.1/docs/Criterion.html#v:env
> ).
>
> One might argue that any potentially confusing NFData instances should be
> written out by hand. Maybe that's right, but now we're drifting into the
> same territory as discussions about Foldable (,a). I've never needed to
> take the length of a tuple, but the Foldable (,a) instance is lawful, so we
> have it in base and I wouldn't be surprised if someone, somewhere is
> thankful for that instance.
>
> Travis
>
> On Tue, Jan 14, 2020 at 5:24 PM David Feuer <david.feuer at gmail.com> wrote:
>
>> 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/6e1fe4dc/attachment.html>