Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add NFData1 and NFData2 classes #21

Merged
merged 10 commits into from
Nov 20, 2016
Merged

Add NFData1 and NFData2 classes #21

merged 10 commits into from
Nov 20, 2016

Conversation

phadej
Copy link
Contributor

@phadej phadej commented Oct 11, 2016

Resolves #8

TODO:

  • changelog
  • rest of tuple instance
  • question: what to do with non-parametric instances, like Ratio pre GHC 8 (numerator and denominator require Integral)
  • generic derivation of NFData1

ping @hvr @RyanGlScott

@phadej
Copy link
Contributor Author

phadej commented Oct 11, 2016

GHC 7.8.3 build couldn't install GHC

@RyanGlScott
Copy link
Member

Having generics support for NFData1 would be nice. You already have most of the machinery—you'd just need something like ToArgs (from aeson) to thread through the function argument to liftRnf, and add cases for the Generic1–specific representation types where necessary.

And to answer your question of what to do with Ratio/Complex: I think it'd be fine to define them conditionally, and make a note of this in their Haddocks.

@RyanGlScott
Copy link
Member

Three weeks have passed since https://mail.haskell.org/pipermail/libraries/2016-October/027385.html, and there were no objections, so I see no problem with moving forward with this. Make sure to address the checklist in #21 (comment), as well as my comments in #21 (comment).

@hvr hvr modified the milestone: 1.4.3 Nov 17, 2016
@phadej
Copy link
Contributor Author

phadej commented Nov 17, 2016

Only generic derivation is left.

@phadej
Copy link
Contributor Author

phadej commented Nov 17, 2016

And Generic1 => NFData1 is done too.

@phadej
Copy link
Contributor Author

phadej commented Nov 17, 2016

And finally green (I hope).

Copy link
Member

@RyanGlScott RyanGlScott left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looking good. I've left some feedback in inline comments.

@@ -144,9 +156,32 @@ case_4_4 = testCase "Case4.4" $ withSeqState 0xffffffffffffffff $ do
genCase n | n > 1 = Case4c (SeqSet n) (genCase (n-1))
| otherwise = Case4b (SeqSet 0) (SeqSet 1)

#if __GLASGOW_HASKELL__ >= 706
case_4_1b = testCase "Case4.1b" $ withSeqState 0x0 $ do
evaluate $ rnf1 $ (Case4a :: Case4 SeqSet)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A minor point, but there's quite a bit of code re-use between the case_4*s and the case_4*bs. It'd be nice to split out the values that get rnf'd into separate top-level bindings.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

won't do now. As there's the hack, and luckily GHC don't float the definitions, and test break. (That's the reason why I cannot bundle them, and must have separate test cases)

rnf = rnf . getProduct
instance NFData a => NFData (Product a) where rnf = rnf1
instance NFData1 Product where
liftRnf r (Product x) = r x

-- |@since 1.4.0.0
instance NFData (StableName a) where
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • NFData1 StableName?
  • NFData1 IORef?
  • NFData1 (STRef s)/NFData2 STRef?
  • NFData1 MVar?
  • NFData1 Ptr?
  • NFData1 ForeignPtr?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NFData2 STRef doesn't make sense, or does it?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's well kinded, at least, as STRef as two type parameters of kind *.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

instance NFData a => NFData1 (Const a) where
liftRnf _ = rnf . getConst
instance NFData2 Const where
liftRnf2 r _ = r . getConst

#if __GLASGOW_HASKELL__ >= 711
instance (NFData a, NFData b) => NFData (Array a b) where
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NFData1 (Array a)?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@@ -355,7 +406,11 @@ instance NFData (a -> b) where rnf = rwhnf

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This might be a contentious point (given the existence of #16), but there could be NFData1 ((->) a) and NFData2 (->) instances.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

won't do

@@ -327,12 +373,16 @@ instance NFData Word64 where rnf = rwhnf
#if MIN_VERSION_base(4,7,0)
-- |@since 1.4.0.0
instance NFData (Proxy a) where rnf Proxy = ()
instance NFData1 Proxy where liftRnf _ Proxy = ()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Make sure to add @since annotations for each of these new instances.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure if it's necessary, as that's implied by the fact NFData1 didn't exist before 1.4.3.0 anyway. But I'll add them anyway.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

-- | A class of functors that can be fully evaluated.
--
-- @since 1.4.3.0
class NFData1 f where
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It'd be nice to have some documentation describing how to derive NFData1 generically, similarly to the current documentation that NFData has here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

instance NFData (Ptr a) where
rnf = rwhnf
-- |@since 1.4.3.0
instance NFData1 MVar where
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think if you changed this to instance NFData1 Ptr, the Travis build would work again ;)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

corrected

@@ -3,6 +3,9 @@
#if __GLASGOW_HASKELL__ >= 702
Copy link
Member

@hvr hvr Nov 20, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI, I'm seriously considering dropping support for GHC < 7.4 with the next deepseq release to get rid of all this CPP cruft

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If's up to CLC I guess?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well, formally I'm the maintainer of deepseq, c.f. https://wiki.haskell.org/Library_submissions#The_Libraries

That being said, if the CLC objects I'd listen :-)

Copy link
Member

@RyanGlScott RyanGlScott left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@RyanGlScott RyanGlScott merged commit 418856a into haskell:master Nov 20, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants