rmap / *recursion-limit* not respected through custom generators
Description
Environment
Activity

Alex Miller June 29, 2016 at 7:58 PM
I would create a new ticket unless it's substantially similar to this one, in which case you can re-open it.

Leon Grapenthin June 29, 2016 at 3:15 PM
@Alex Miller - I haven't had time yet to check whether latest design changes especially in spec.test solve recursion through custom generators or make it obsolete. The examples given in above description have clearly been solved but they were only examples for a larger problem. Would you like me to change this ticket or should I create a new one?

Alex Miller June 29, 2016 at 3:58 AM
As of Clojure 1.9.0-alpha8, due to changes in map-of etc, s/exercise now works on this example.

Alex Miller June 25, 2016 at 3:37 PM
Please re-check this after the next alpha - there are a lot of changes happening in this area.

Leon Grapenthin June 19, 2016 at 11:08 PM
I have changed the issue because in the former description I had made some assumptions that I could prove incorrect by studying the implementation a bit more.
Details
Details
Assignee
Reporter

Approval
Priority

In all cases where a custom generator is used, the recursion limit is not respected.
This limitation becomes clear when one tries to build a recursive spec around e. g.
s/coll-of
because it uses a custom generator vias/coll-gen
. Runnings/exercise
on it quickly blows the stack.Here is an example for illustration with
s/map-of
(s/def ::map-tree (s/map-of keyword? (s/or :tree ::map-tree :leaf nil?)))
Even though
s/or
implements recursion checking, it is deceived here and not able to detect itself being called subsequently because the custom generator ofs/coll-of
(used ins/map-of
) doesn't/can't passrmap
(keeping track of recursion calls) through tos/or
'sgen*
.For the concrete case,
coll-of-impl
could be implemented that would implement agen*
that passes onrmap
.For the general case of custom generators the challenge would be that test.check generators don't take and pass on
rmap
to generators of specs they potentially reuse and that there is no well-defined behavior for what they themselves should do when the recursion-limit has been reached. Ideas are:reduce generator size when recursion is detected (this is the strategy used in recursive specs of test.check use(d)?)
expose the recursion-limit / rmap mechanism to the user so that custom generators can pass it on to subsequent calls of specs. E. g. a custom generator is passed a context object that it should pass to
s/gen
as an optional argument