Falsify: Hypothesis-Inspired Shrinking for Haskell (2023)
1–10 of 20 posts
Re: Falsify: Hypothesis-Inspired Shrinking for Haskell (2023)
#2How does Hedgehog and Hypothesis differ in their shrinking strategies?
The article uses the words "integrated" vs. "internal" shrinking.
> the raison d’être of internal shrinking: it doesn’t matter that we cannot shrink the two generators independently, because we are not shrinking generators! Instead, we just shrink the samples that feed into those generators.
Besides that it seems like falsify has many of the same features like choice of ranges and distributions.
Re: Falsify: Hypothesis-Inspired Shrinking for Haskell (2023)
#3This is fascinating!
If I understand correctly, they approximate language of inputs of a function to discover minimal (in some sense, like "shortest description length") inputs that violate relations between inputs and outputs of a function under scrutiny.
Re: Falsify: Hypothesis-Inspired Shrinking for Haskell (2023)
#4 newtype Parser a = Parser ([Word] -> (a, [Word])
Re: Falsify: Hypothesis-Inspired Shrinking for Haskell (2023)
#5[deleted]
Re: Falsify: Hypothesis-Inspired Shrinking for Haskell (2023)
#6I’m honestly completely failing to understand the basic idea here. What does this look like for generating and shrinking random strings,
Re: Falsify: Hypothesis-Inspired Shrinking for Haskell (2023)
#7I've found in practice that shrinking to get the "smallest amount of detail" is often unhelpful.
Suppose I have a function which takes four string parameters, and I have a bug which means it crashes if the third is empty.
I'd rather see this in the failure report:
("ldiuhuh!skdfh", "nd#lkgjdflkgdfg", "", "dc9ofugdl ifugidlugfoidufog")
than this:
("", "", "", "")
Re: Falsify: Hypothesis-Inspired Shrinking for Haskell (2023)
#8I care about the edge between "this value fails, one value over succeeds".
I wish shrinking were fast enough to tell me if there are multiple edges between those values.
Re: Falsify: Hypothesis-Inspired Shrinking for Haskell (2023)
#9I've found in practice that shrinking to get the "smallest amount of detail" is often unhelpful. Suppose I have a function which takes four string parameters, and I have a bug which means it crashes if the third is empty. I'd rather see this in the failure report: ("ldiuhuh!skdfh", "nd#lkgjdflkgdfg", "", "dc9ofugdl ifugidlugfoidufog") than this: ("", "", "", "")
Really? Your examples seem the opposite. I am left immediately thinking, "hm, is it failing on a '!', some sort of shell issue? Or is it truncating the string on '#', maybe? Or wait, there's a space in the third one, that looks pretty dangerous, as well as noticeably longer so there could be a length issue..." As opposed to the shrunk version where I immediately think, "uh oh: one of them is not handling an empty input correctly." Also, way easier to read, copy-paste, and type.
Re: Falsify: Hypothesis-Inspired Shrinking for Haskell (2023)
#10I've found in practice that shrinking to get the "smallest amount of detail" is often unhelpful. Suppose I have a function which takes four string parameters, and I have a bug which means it crashes if the third is empty. I'd rather see this in the failure report: ("ldiuhuh!skdfh", "nd#lkgjdflkgdfg", "", "dc9ofugdl ifugidlugfoidufog") than this: ("", "", "", "")
Really? Your examples seem the opposite. I am left immediately thinking, "hm, is it failing on a '!', some sort of shell issue? Or is it truncating the string on '#', maybe? Or wait, there's a space in the third one, that looks pretty dangerous, as well as noticeably longer so there could be a length issue..." As opposed to the shrunk version where I immediately think, "uh oh: one of them is not handling an empty inp…
Their point is that in the unshrunk example the “special” value stands out.
I guess if we were even more clever we could get to something more like (…, …, "", …).