What’s the standard tactic for taming optionally recursive data structures? E.g. I have a foo that may also contain a foo under ::child; sampling the generator takes a long time because it generates huge foos

huge foos because of the recursion?

Yep.

Realistically the number of recursions for real data is like, uh, 1. Most applications won’t do the recursion beyond that 1 level, but some might. Generating “deep” trees is fine and a useful test, but I’d prefer to have it generate wider trees instead (because now generation is taking a while). I’m not super sure yet if it’s actually taking a while or if it’s just CIDER’s repl view that’s super slow or both.

have you messed with http://clojure.github.io/clojure/branch-master/clojure.spec-api.html#clojure.spec/*recursion-limit* at all?

Having a similar issue, trying to control size of a tree. I don't think *recursion-limit* is working for me. Exercising the spec below sometimes gives results that violate the recursion limit, or even generate a stack overflow.

Seems a lot better behaved if I redefine as follows. Not sure if this is expected:

At least I'm not getting stack overflow errors with this case, though trees appear to sometimes be fairly deep regardless of *recursion-limit*, but maybe that's what the docs mean by it being a "soft limit".

What do I need to require to use exercise-fn? With clojurescript 1.9.225 and test.check 0.9.0 I get the following error: #object[Error Error: Var clojure.test.check.generators/->Generator does not exist, clojure.test.check.generators never required]. This is in a namespace where I've required [cljs.spec :as s :include-macros true], [cljs.spec.test :as st :include-macros true] and [clojure.test.check.generators :as gen :include-macros true].

alexmiller: I have not; messing with a global dynamic var seems inappropriate, I want to affect this specific recursiveness

@lvh do it in a bindings