Documentation

Uniformly choose among any number of alternatives, dropping the empty ones. Plain <|> only combines two generators at 50/50, so chaining it over more than two alternatives associates pairwise and skews weight towards whichever branch ends up outermost in the resulting tree instead of splitting evenly — use this instead whenever there are more than two alternatives to pick fairly among.

Supplies a Show instance derived from showP.

falsify's Show instance for Fun needs Show on both parameters, and we only ever have TestingEqShow. Rather than reinterpret a Fun a b at the wrapped type after the fact, GenFun generates at Fun (ShowP a) (ShowP b) from the start, so show applies directly and no coercion is involved. applyFunP unwraps on the way back out.

Apply a generated function, wrapping and unwrapping the ShowP it was generated at. Both directions are ordinary newtype constructor applications.

True if a type's generator is non-empty. A pure check on TestableTypes gen — it doesn't sample anything, so it's safe (and cheap) to call as many times as convenient, e.g. once in a genSuchThat predicate and again via the real gen/genNamed call that actually produces a value.

Resample genKey (cheaply, within Gen) up to maxTries times until isUsable accepts the draw, before ever asking Property to commit to a choice.

Property-level discard restarts the *whole* property from scratch (and can trip falsify's per-slot discard-ratio limit, aborting the entire test run early) — so when a later, dependent draw (e.g. "a morphism out of this object") is likely to be empty for a "bad" choice made here, it's far cheaper to reject that choice immediately, inside Gen, than to commit to it via Property and let the dependent draw discover the problem. A choice that's still unusable after maxTries attempts is returned anyway, so a genuinely unsatisfiable requirement still falls through to whatever ordinary discard the caller's own dependent generation triggers.

How many times genSuchThat resamples before giving up. There's no principled formula for this — it depends on how sparse the specific requirement being searched for is, which genSuchThat has no way to know in advance. 100 is a pragmatic default: comfortably more than the number of candidates a small test object palette usually offers (so a single unlucky pick is very unlikely to exhaust it), while still cheap, since each attempt is a plain Gen sample rather than a Property-level discard.

genOb, but resampled (see genSuchThat) until isUsable accepts the object.

Recover Ob a from TestOb a (the Testable superclass entailment), packaged as a function so that call sites with other quantified givens in scope (e.g. the comonoid supply of a CopyDiscard category, whose head has Ob as a superclass) don't have to rely on GHC expanding superclasses of quantified-constraint heads. Observed on GHC 9.10.3: with such a given in scope, \r -> r at this type fails with "Could not deduce Ob a", while the same lambda compiles without it (cf. propSymMonoidal_ versus propCopyDiscard_). Likely a solver limitation; retry dropping this helper after a GHC upgrade.