deepseq: Add more instances. #50

[Travis Whitaker]

I don't understand what the NFData class has to do with compact regions.
It's true that placing a value into a compact region causes it to be
evaluated to normal form, but NFData instances are not used for this. In
fact, there are objects that have a reasonable normal form but cannot be
placed inside a compact region. StableName is an example of this, and it
has an NFData instance already. Here's a GHCI session demonstrating this
(GHC 8.6.5):

>>>import Data.Compact
>>>import System.Mem.StableName
>>>x = 1 :: Int
>>>xsn <- makeStableName x
>>>c <- compact xsn
*** Exception: compaction failed: cannot compact mutable objects
>>>import Control.DeepSeq
>>>rnf xsn
()



On Wed, Jan 15, 2020 at 3:43 AM Andrew Martin <andrew.thaddeus at gmail.com>
wrote:

> My understanding of the argument for and against is:
>
> * For: Typeclass instances should be provided for as many types as
> possible, and IORef, TVar, etc. only admit a single way to define NFData
> * Against: Intuitively, NFData means that data is plain old sums and
> products all the way down, all of which can be forced. This would mean that
> anything with an NFData instance should be able to go into a compact region
> (except that pinned byte arrays, and consequently bytestrings, cannot)
>
> I'm inclined to agree with most of the opinions expressed earlier on the
> thread. That is, given how minor the convenience is, the confusion is
> probably not worth the convenience. I'll think about this more today.
>
> On Tue, Jan 14, 2020 at 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
>>
>
>
> --
> -Andrew Thaddeus Martin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20200115/05d03be7/attachment.html>