The goal: the sandbox initially maintains a shallow trace. As you expand
into the trace, the environment reruns the sandbox at greater depth as
needed.
The challenge: expanding happens within edit-trace, which doesn't have
the whole sandbox needed to re-run the sandbox. We'll either need to expand
the trace's capabilities to include the whole sandbox, or duplicate some
logic to decide when to run the sandbox.
So far we were only doing so for the first few lines, just enough to render
one page's worth of lines. We'd have probably noticed if we collapsed some
lines after re-evaluating.
I've been stymied for a week wondering how to reliably compute trace-line
identity. A trace can have multiple identical lines. Only some of them
may be visible at any point. How to remember which is which across re-evaluations?
There's no easy answer. I'm just going to keep things ad hoc. When you
re-evaluate, new lines can currently pop into visibility. However we guarantee
that just moving around the trace will be stable, thanks to the visible
bit being cached within each trace-line. Scrolling will be similar. Reevaluating
may cause the trace to be perturbed up or down. However, just scrolling
around will work reliably.
We now use traces everywhere for error-checking. Null traces introduce
the possibility of changing a functions error response, and therefore its
semantics.
Kartik K. Agaram