top-level into `spy`?

[shriram]

Would it make sense for top-level output to be wrapped in spys and printed accordingly? We have a problem where, when you have lots of top-level expressions, it's hard to keep track of which output came from which expression. spy already addresses this issue by providing hyperlinks back to the origin.

[blerner]

Argh. We actually have much of this; it's called tracing, and it already exists and you hated its UI. You thought the outputs were too visually noisy all the darn time (especially for the flags assignment, where you sometimes relied on visual puns for showing two images directly above each other). The top-level output of any program is already piped through a JS function called traceOuptut, which is now rigged to be the identity function on HTML output. In the past it numbered your outputs in small (~5pt) text. Rigging it to contain srclocs is tricky but perhaps doable. But this is an all-or-nothing deal: are you willing to change how all top-level outputs (including REPL interactions) display?

[jpolitz]

FWIW, I didn't like the labelled UI we had either.

I wonder if sticking some information all the way over on the right about the line the value came from would be useful.

I agree with @blerner that this is all-or-nothing; we have to consider its effects across curricula. But that effect could be positive – a BS:A student could benefit from seeing which expression produced which shape (or even that the two red squares that output came from two different lines, one with a call to square and one with a call to rectangle).

[jpolitz]

Just as an FYI, traceValue already takes a srcloc along with the value, so there's no extra compiler plumbing to do. We could even use the srcloc to tell which traces are coming from definitions vs. interactions.

It boils down to a UI question, which I think we wisely decided to defer (to match WeScheme's behavior, and to avoid adding elements that users would come to rely on).

[blerner]

Oh good, I'm glad we did that plumbing already, then. Good thinking, earlier us!

[shriram]

All the way over on the right is one place. Why not something you can mouse over on the left (like the error message on-demand color highlights)? There's nothing that says values must print flush with the left column…

[shriram]

Okay, concrete proposal. When you hover over a value printed (after Run) in the interactions window, hovering over the value will flash the corresponding input expression in the definitions window using the same mechanism as the flasher in error messages. It will scroll to find the expression if needed. Each value's flasher will be given a different color, to make it easier to tell them part.

Please critique.

(This does not make an allowance for multiple expressions to all be highlighted: you can't make the highlighting "sticky", since that will require clicking, which may affect other click-based things we want to do, such as alter the presentation of numbers.)

[blerner]

We had a firm rule that merely moving the mouse to hover over something should not cause the definitions area to scroll, because rapidly moving your mouse over multiple such triggers would be really disorienting. Plus, just because your mouse happens to move over something doesn't mean you wanted to lose your context on the left side of the screen. That's why we have the up and down black-arrows-on-red-highlight-bars UI at all, rather than immediately scrolling the definitions area. Affirmatively clicking on something was our signal to scroll the definitions area.

[schanzer]

Given that we already have a metaphor for "hey! click here to see where this came from!", it certainly makes sense to reuse it.