Live Projectors

[disconcision]

Update:

There's a walkthough docs slide now, called Probes, which is a better introduction than the below: https://hazel.org/build/projectors-live/.

This give projectors access to dynamic info about their underlying term. In particular, it adds a new Probe projector which can be applied to any convex-tile expression term. When an expression is probed, live cells are added to the right of the row where the projector is located. Each live cell represents a closure resulting from that expression's evaluation. Each closure stores a value and and environment, where the environment is restricted to variable references which are locally free in the probed expression (ie occurring in the expression's co-context). Each closure additionally tracks a frame stem, a stack of environment ids which is used to associate closures drawn from the same (nested) function execution(s).

Current interaction model (TL;DR):

Try:

• Pressing alt/option-v when any convex-tiled expression is indicated to add a probe
• Clicking/hovering/double-clicking/shift-dragging on a live cell
• Add multiple projectors across nested function literals and observe the effect of clicking on different live cells.

Current interaction model (detailed):

• Use the projector panel or alt/option-v to apply a probe projector to any convex-tile expression (you'll have to parenthesize otherly-shaped things, same as with other projectors)
• If the dynamics are still calculating, or if the expression is never executed, the probe icon will spin
• If closures are found for that expression, the number of closures are indicated in the probe superscript
• By default, live cells based on all gathered closures are shown; double-clicking on any cell restricts that probe to show only that one cell.
• Hovering over a live cell shows the (co-contextual) environment (for expressions which are not variable references which contain variable references).
• Clicking on a live cell sets a global (across-probe) frame cursor to that closure's frame stem. What this means is that an indication decoration (dotted outline) will be drawn on other cells from other probes that were gathered as part of the same function application (or nested application, for function literals contained inside other function literals). This is slightly complicated to explain, but hopefully evident from clicking around a bit.
• Note that if some probes are set to show only one live cell (by double-clicking on a cell), which cell is shown may change as you select live cells in other probes. This is because the cell shown for each 'collapsed' probe is the first one compatible with the current frame cursor, i.e. the first one that would have a dotted outline around it as per above.
• To expand/contract cell size (currently one size setting for each probe), hold shift and carefully drag the first cell of a probe left/right to progressively un/summarize the value. This is still finicky.
• Adding two probes on the same line will currently result in their cells overlapping; you can manually add a linebreak to work around this
• You can click on the in-line projector probe UI to zero out the frame cursor (if it's distracting)

Bugs:

• ap pinning only works for top level calls
• dynamic cursor should move with offset arrows
• double-clicking on cell doesn't offset to that cell
• default cutoff cell display should advance to first indicated cell
• pattern cells missing their underline
• i've broken all pattern projector splicing somehow
• prevent use on patterns (via keyboard shortcut)
• ap indication for pattern probes
• in fib example, indicating some closures doesn't indicate call site

Features:

• move some (?) cells to beginning? under some conditions?
• consider extricating fontmetrics from core
• grab ellipses to resize?
• double click to pin aps
• add indication that cell list is cut off even when not indicated
• docs slide
• group cells by application
• Integrate side view into projectors API
• indicate the relevant ap (if probed) when inside a closure created by that ap
• Show keyboard shortcuts on hover on projector panel
• per-cell resize states (should this be for a given closure or position in the cell list)
• probes on pattern variables
• callstack-based ap indication
• make closure collection a projector API flag to prevent perf issues
• cut off live cells after 20 or so, add nav arrows

Features/fixes deferred to future PRs:

• Feature: Projectors ExplainThis
• Feature: Projectors from selections (auto-parentheses)
• Feature: Projectors expose underlying static errors
• Feature: Improve value summarization logic
• Feature: Adding a new probe on the same line as another removes the first
• Feature: Annotation projector: (put indicator over syntax instead of replacing it, enabling editing)
• Feature: Probe keyboard focus (move closure cursor, resize cell, resize cells bound)
• Issue: Make exercise mode your-impl get probe data from your-tests
• Issue: Make shift-resize abbreviation mouse capture less finicky

[disconcision]

@Negabinary this is only tenuously out of draft but i'd appreciate a look-over when you get the chance, especially regarding the dynamics bits. Currently I'm doing some things a bit hackily and trying to decide how bad they actually are.

There are two dynamics things in particular I'm wondering about:

1. Regarding exercise mode dynamics work. I was able to hook up to it in a basic sense, but I'm confused about dynamics across cells. Currently, probes in the correct implementation reflect values from the tests, but the user implementation probes don't reflect values from the user tests, only for executions in the user implementation editor itself. Changing the ExercisesMode piping so that the user implementation cell gets the user test dynamics also doesn't seem to make this work. (As a larger issue, it's not 100% clear to me what should get what. Also, I think I/we should consider, possibly as part of this PR, changing the way dynamics output works to make it slightly more in-line with statics. in particular, maybe dynamics should output a map, and there is just implictly a probe on the syntax root. i.e, the previous dynamics results is now 'just' an entry in the map. This clarifies my interfaces a bit but maybe fucks with stepper stuff?)
2. Another thing I don't quite understand is that in the current implementation, i'm not actually really accumulating a stack trace... it seems to be more of a lexical equivalent. i.e. I would have expected the current implementation to, if i instrument a variable x inside a function bound to f, defined at the top level, which is called inside a function g, also defined at the top level, and then g is called at the top level, to have entries corresponding to both f and g for variable x. but it only has the immediate call. this doesn't actually immediately matter but I want to understand why my understanding of the code is wrong.

P.S. I did some dead code removal in ClosureEnvironment as I was finding the interface was drifting a bit