deepseq: Add more instances. #50

[Travis Whitaker]

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/8904874e/attachment.html>