Proposal #3537: Add missing NFData instances to parallel

View: New views
7 Messages — Rating Filter:   Alert me  

Proposal #3537: Add missing NFData instances to parallel

by Roel van Dijk-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

Re: Proposal #3537: Add missing NFData instances to parallel

by Gregory Collins-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Roel van Dijk <vandijk.roel@...> writes:

> 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 <greg@...>
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

Re: Proposal #3537: Add missing NFData instances to parallel

by Roel van Dijk-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

> 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.
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

Re: Proposal #3537: Add missing NFData instances to parallel

by Simon Marlow-7 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

Re: Proposal #3537: Add missing NFData instances to parallel

by Roel van Dijk-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

> 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?
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

Re: Proposal #3537: Add missing NFData instances to parallel

by Simon Marlow-7 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries

Re: Proposal #3537: Add missing NFData instances to parallel

by Roel van Dijk-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

>> 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.
_______________________________________________
Libraries mailing list
Libraries@...
http://www.haskell.org/mailman/listinfo/libraries