Open art-w opened 2 years ago
I tried to understand how the length of lists is controlled; reading the source I came across the size
parameter but could not see how it is initialized. A comment in the code of its role and initialization would be useful.
This proposal might not be the right bandage (maybe just expanding the documentation of
choose
would be better.) I ran into some issues with a recursive generator that was failing to terminate. Reading crowbar source code, there's asize
fuel mechanism in place to shortcut the random generation by choosing the first availableconst
/primitive
when the generated term grows too much -- but my leaves were wrapped in amap [..]
and so the shortcut couldn't trigger (for example, see the xmldiff test where knowledge of the optimization edge-case yields a manual unrolling).Some random comments:
small_examples
was a list of candidates, but then the shortcut would always pick the first one (such that it could have been anoption
): https://github.com/stedolan/crowbar/blob/0cbe3ea7e990a7d233360e6a74b1cb5e712501ad/src/crowbar.ml#L246 Perhaps the plan was to select a random value from that list? (but the current behavior has the advantage of not consuming more random bits)choose
would previously crash at this point: https://github.com/stedolan/crowbar/blob/0cbe3ea7e990a7d233360e6a74b1cb5e712501ad/src/crowbar.ml#L252 PerhapsChoose []
could be simplified away by the smart constructors -- but this would push the "non-empty generator" constraint tounlazy
/bind
, it's not clear that this would be better.const
/primitive
as before, and default to themap
/bind
otherwise (but I think it's easier to predict the default value when it's always the first element ofchoose
)afl-fuzz
is able to avoid triggering it too much?(unrelatedly, the
xmldiff
test seems to work on my computer -- however thecalendar
test crashes very fast!)