{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreigjutwvlvbnegk5lj2lsd4leqcrdutmc6bmk4zhvi5ni67mfb5wcq",
    "uri": "at://did:plc:pi6woz4d47bkuws673w2il2r/app.bsky.feed.post/3mif77n3uxj22"
  },
  "path": "/t/why-not-use-smallcheck/13860#post_8",
  "publishedAt": "2026-03-31T16:16:24.000Z",
  "site": "https://discourse.haskell.org",
  "textContent": "I guess I understand to little how depth works in `smallcheck`. In my `tinycheck`, you could simply define something like:\n\n\n    string :: TestCases String\n    string = arbitrary\n      <> (unwords <$> arbitrary)\n      <> (unlines . fmap unwords <$> arbitrary)\n\n\nand you’d get strings, strings separated by spaces, strings separated by spaces and newlines both very early on. If it’s important to have spaces and newlines, then you can simply merge a generator that produces them into the default one.\n\nOr if you need longer strings, you can do:\n\n\n    atLeast :: Int -> TestCases String\n    atLeast n = (<>) <$> replicateM n arbitrary <*> arbitrary\n\n\nMy point is, if you have requirements of some specific data showing up in the generator, then fix the generator. But I don’t see how there is a fundamental limitation to enumerating values.\n\nOk, here is maybe one thing: The concept of depth is maybe too restrictive. My approach here is to just enumerate in some order ad hoc, without keeping track precisely how deep we are going. If we need a few deeper values early on, just mix them into the generator. Keeping track of depth is not necessary, we can just restrict the number of test cases instead.",
  "title": "Why not use smallcheck?"
}