deepseq: Add more instances. #50

chessai . chessai1996 at
Wed Jan 15 04:15:48 UTC 2020

David put my thoughts pretty clearly: is it more useful or more confusing?
I am also leaning toward more confusing. Hopefully more can weigh in on

On Tue, Jan 14, 2020, 7:06 PM David Feuer <david.feuer at> wrote:

> 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>
> wrote:
>> Thanks for your email, David.
>> The NFData class is an important part of a large number of APIs on
>> Hackage. According to, 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 (
>> ).
>> 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>
>> 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>
>>> wrote:
>>>> Greetings Haskellers,
>>>> I am writing to draw your attention to
>>>> 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
>>> _______________________________________________
> Libraries mailing list
> Libraries at
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list