-
Notifications
You must be signed in to change notification settings - Fork 178
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
Strictness tests for Map construction #1021
Strictness tests for Map construction #1021
Conversation
e1017c8
to
3cd7e25
Compare
Alright, this is good to go. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I haven't read it all yet, but I have a few thoughts.
prop_strictFromSet fun set = | ||
isBottom (M.fromSet f set) === any (isBottom . f) (Set.toList set) | ||
where | ||
f = coerce (applyFunc fun) :: OrdA -> A |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the explicit coerce
here reduces clarity without (at least meaningfully) improving test performance. Less importantly: I think Bot A
is overkill; Bot ()
should do the trick. That change should improve test performance by reducing the number of random numbers generated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think the explicit
coerce
here reduces clarity without (at least meaningfully) improving test performance.
In all of the tests with functions, the point is to get some X -> Y
where Y
may be bottom. This is done by generating Func X (Bot Y)
and using coerce . applyFunc
on it. It is true that some tests would work without the coerce
, but I don't see a good reason to deviate from the standard pattern.
Less importantly: I think
Bot A
is overkill;Bot ()
should do the trick. That change should improve test performance by reducing the number of random numbers generated.
This is true for this test, but again there is little reason to deviate. The tests run fast and I don't think it is worth trying to optimize tests case-by-case unless it is really causing a problem.
@treeowl do you have more comments on this? |
ceaaae0
to
7f4d14e
Compare
I'll check this once for problems and merge if it seems fine. |
38a9c14
to
53f6be5
Compare
This aims to reduce the chance of introducing strictness bugs. Since we use the same Map type for lazy and strict maps, it is not possible to ensure appropriate strictness at the type level. So we turn to property tests. Arbitrary Set and Map generation is moved from set-properties.hs and map-properties.hs to ArbitrarySetMap.hs to be shared with the new strictness tests.
53f6be5
to
b6fee41
Compare
Alright, it's looking good. |
For #1019.
Adds a bunch of property tests that try to create strict and lazy
Map
s with bottom values and check if the result map is bottom.We also need to do
IntMap
but this PR is already huge, will do that later.