{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreihuncgba6bsma42nvzswrfuzfv7nhynzxsxcmtthk7jtizcp6lhde",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mivyxjovhsy2"
  },
  "path": "/t/why-not-use-smallcheck/13860#post_20",
  "publishedAt": "2026-04-07T14:22:59.000Z",
  "site": "https://discourse.haskell.org",
  "textContent": "I see your point, but I still find that this is a too narrow view on how to treat depth. Here, you implicitly identify depth with length of the array. This would lead to an unusable implementation. For example, `[Integer]` would enumerate all (i.e. infinitely many) one-element lists before the 2-element lists. Clearly this is not what we want. It’s not what `tinycheck` implements, and I assumed until now it’s not what `smallcheck` implements?\n\nFor your specific example, for a threshold of 18, `tinycheck` finds the bug after less than 2 million (and more than 200 000) values, which takes 0.3 seconds on my machine. (1.4 seconds for a threshold of 20, still less than 2 million values.) I agree that this is probably less performant than QuickCheck, but still I find it noteable. I achieved it by just writing down the basic idea behind SmallCheck from memory in little time as a library. This says something about the power of the idea.",
  "title": "Why not use smallcheck?"
}