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@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.TravisOn Tue, Jan 14, 2020 at 5:24 PM David Feuer <david.feuer@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@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@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
Libraries mailing list
Libraries@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries