deepseq: Add more instances. #50

David Feuer david.feuer at
Wed Jan 15 01:24:34 UTC 2020

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>

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the Libraries mailing list