search

haskell / deepseq

Deep evaluation of data structures
http://hackage.haskell.org/package/deepseq
Other
41 stars 28 forks source link

remove NFData instance for a -> b #47

Closed chessai closed 1 year ago

chessai commented 5 years ago

resolves #16

cartazio commented 5 years ago

@ekmett @hvr i was trying to understand the associated ticket: is the issue that functions / closures can't be deepseq'd wrt the references in their closure? or am i missing something about which sense its deemed unimplementable? (would some evil CMM of doom help?)

hvr commented 5 years ago

note that this is for a next major version of deepseq -- a cost which I'm rather reluctant to impose upon the ecosystem (due to the amount of reverse deps) until there's breaking changes beyond the mere removal of the -> instance prompting a major version increment.

Btw, I'd like to know what other instances fall into the same category as NFData (a -> b) which ought not exist; I for one would think that if we consider the instance for a -> b to be unsound, we'd also consider IORef et al. to be unsound which similar to a->b also lack instances such as Show (see e.g. https://mail.haskell.org/libraries/2016-May/026966.html). It seems inconsistent to me to single out a -> b while tolerating other instances which IMO are morally similar in their uneval-thunk-leaking. And given we've had this instance for ages, I'd also want to see a rationale/justification documented for why there shall not be any a -> b instance in the Haddocks as a note.