Exercise 3: Predicting the Recursion Depth at Limit 2000 — Possible Solution
====================================================================

THE TWO KNOWN DATA POINTS (from the chapter)
------------------------------
    Python recursion limit 1000  ->  Wisp max working depth 163
    Python recursion limit 3000  ->  Wisp max working depth 497

LINEAR PREDICTION
------------------------------
    slope = (497 - 163) / (3000 - 1000) = 334 / 2000 = 0.167

    predicted depth at limit 2000
        = 163 + 0.167 * (2000 - 1000)
        = 163 + 167
        = 330.0

MEASURED RESULT (binary search using sys.setrecursionlimit(2000))
------------------------------
    Max working depth at limit 2000:  330

    The prediction and the measurement match exactly.

WHY THIS WORKS AS AN ANSWER
------------------------------
Yes, the relationship is linear, and this is the expected outcome, not
a coincidence specific to these three numbers. Every single Wisp-level
recursive call to countDown() costs the SAME fixed number of real
Python stack frames every time -- accept() on the Call node, then
visit_call(), then WispFunction.call(), then execute_block(), then
accept() on the if statement inside the body, and so on down a fixed
chain before the next countDown() call happens. Call that fixed
per-level cost k. If the interpreter can use roughly (limit / k) levels
of Wisp recursion before Python's own limit is reached, then Wisp's
own usable depth scales directly, proportionally, with Python's limit
-- a straight line through the origin-ish region, matching what was
measured here (slope ~0.167, meaning each Wisp-level countDown() call
costs roughly 1/0.167 = ~6 real Python stack frames, consistent with
the actual chain of accept()/visit_call()/call()/execute_block()/
accept() calls named above).

This is also exactly why this interpreter has no Wisp-specific
recursion limit of its own to tune -- the relationship is a fixed
multiple of whatever `sys.setrecursionlimit()` says, not an
independent constant. Raising Python's limit further would keep
scaling Wisp's own usable depth by the same ~0.167 factor, right up
until the OS-level C stack itself runs out (a real, separate ceiling
`sys.setrecursionlimit()` cannot raise past, that this chapter's
verification never had to reach for the depths tested here).