(I was unable to post on Jira, so I report here) in the docstring of tuple:
(def t (tuple gen/small-integer gen/boolean))
should be
(def t (gen/tuple gen/small-integer gen/boolean))
let's see if I still have commit rights
I do! it's fixed, thanks
Yesterday I struggled with test.check’s API, I had to use a lot of internal functions and did not see a way to do otherwise. Here is my function:
(defn- decreasing-sizes-gen
"Returns a generator of lazy sequence of decreasing sizes."
[max-size]
(#'gen/make-gen
(fn [rng _]
(let [f (fn f [rng max-size]
(when-not (neg? max-size)
(lazy-seq
(let [[r1 r2] (random/split rng)
size (#'gen/rand-range r1 0 max-size)]
(cons size (f r2 (dec size)))))))]
(rose/pure (f rng max-size))))))
#_(gen/sample (decreasing-sizes-gen 100) 1)
• I had to make my own #'gen/make-gen
because gen/randomized
is not public,
• gen/lazy-random-states
is not public either,
• I did not find an easy way to recursively iterate between using a generated value and using it to feed a new generator.
I am under the impression that, since the public API cannot be complete for sure, make-gen
and rng
should be exposed to the users.
If one day I am writing a successor to test.check, I would build it based on that.
You can't do this with the sizing combinators?
which ones?
sized and with-size, I think
One to get the size, the other to set them
then I would still need a way to build my lazy sequence
map with range
And tuple
It won't be lazy; is that important?
in my case, I could live without, but in the general case, lazy sequence is something with zero support in test.check
I will keep my function as is, but I wanted to report the limitations I found.
Yes. Should be easier to add laziness now that the rng is immutable