Proposal #3537: Add missing NFData instances to parallel
Control.Parallel.Strategies contains many NFData instances for types defined in base, but not all. I propose adding NFData instances for all types in base where it makes sense. The specific issue I had was with Data.Version. I wanted to 'rnf' some type which contained a Version, but it had no instance for NFData. The only solution is to add an instance in your own code, where it doesn't really belong. Therefor I checked the base package for other other types which also lacked an NFData instance. I would like some feedback on the instances for STRef and IORef. Does it make sense to have them? I used a trick to force their evaluation since their constructors are not exported. Discussion deadline: October 7 Ticket: http://hackage.haskell.org/trac/ghc/ticket/3537 Regards, Roel van Dijk
Roel van Dijk
I would like some feedback on the instances for STRef and IORef. Does it make sense to have them? I used a trick to force their evaluation since their constructors are not exported.
This might be "dirty" but what about this instead?
instance (NFData a) => NFData (Data.IORef.IORef a) where
rnf r = unsafePerformIO $ modifyIORef r (`using` rnf)
G.
--
Gregory Collins
This might be "dirty" but what about this instead?
instance (NFData a) => NFData (Data.IORef.IORef a) where rnf r = unsafePerformIO $ modifyIORef r (`using` rnf)
Hmm, I don't know. The question is whether you want to evaluate the value stored inside of the IORef. I think that any function that evaluates a value inside of an IORef should be in the IO monad. I wouldn't expect a function with the type "a -> ()" to be able to "look into" an IORef. The reason I made an NFData instance for IORef is for a situation like this: test :: IO () test = do x <- newIORef () y <- newIORef () let z | hugeConditionalExpression = x | otherwise = y rnf z `seq` doSomething You might want to force z to head normal form to force the evaluation of the hugeConditionalExpression.
On 23/09/2009 18:46, Roel van Dijk wrote:
This might be "dirty" but what about this instead?
instance (NFData a) => NFData (Data.IORef.IORef a) where rnf r = unsafePerformIO $ modifyIORef r (`using` rnf)
Hmm, I don't know. The question is whether you want to evaluate the value stored inside of the IORef. I think that any function that evaluates a value inside of an IORef should be in the IO monad. I wouldn't expect a function with the type "a -> ()" to be able to "look into" an IORef.
The reason I made an NFData instance for IORef is for a situation like this:
test :: IO () test = do x<- newIORef () y<- newIORef () let z | hugeConditionalExpression = x | otherwise = y rnf z `seq` doSomething
You might want to force z to head normal form to force the evaluation of the hugeConditionalExpression.
what's wrong with instance NFData (Data.IORef.IORef a) where rnf r = r `seq` () ? Cheers, Simon
what's wrong with
instance NFData (Data.IORef.IORef a) where rnf r = r `seq` ()
Ah, you are right. I was being to clever for my own good :-) Perhaps it works for all types where I used the "rnf x = rnf (x == x)" trick. Should I attach a new patch to the ticket with those definitions changed?
On 24/09/2009 10:53, Roel van Dijk wrote:
what's wrong with
instance NFData (Data.IORef.IORef a) where rnf r = r `seq` ()
Ah, you are right. I was being to clever for my own good :-) Perhaps it works for all types where I used the "rnf x = rnf (x == x)" trick. Should I attach a new patch to the ticket with those definitions changed?
Sure, that would be helpful. Cheers, Simon
Ah, you are right. I was being to clever for my own good :-) Perhaps it works for all types where I used the "rnf x = rnf (x == x)" trick. Should I attach a new patch to the ticket with those definitions changed?
Sure, that would be helpful.
I have updated the patch attached to the ticket.
participants (3)
-
Gregory Collins -
Roel van Dijk -
Simon Marlow