Open dhess opened 3 years ago
dhess
commented
3 years ago We'll be rewriting eval mode in the new frontend, but I think this is a good summary of some of the major issues in the current implementation, so I'm pulling it along for the ride as reference.
dhess
commented
2 years ago FYI, as we look more closely at the roadmap and the project constraints for the coming year, eval mode has been relegated to a "nice to have" rather than a "must have." This is disappointing given how important I think this feature is, but it's clear that it still needs a lot of work, I think it will be a multi-month project at best, and I just don't see how it's realistic to ship this by the end of the year at this point.
annedino4
commented
2 years ago FYI, as we look more closely at the roadmap and the project constraints for the coming year, eval mode has been relegated to a "nice to have" rather than a "must have." This is disappointing given how important I think this feature is, but it's clear that it still needs a lot of work, I think it will be a multi-month project at best, and I just don't see how it's realistic to ship this by the end of the year at this point.
We have talked about the possibility of a demo version, it could be a small demo product or an animation created by me. Either way, we'll need to optimise the design, I'll start working on it after finalising our current tree design tasks, as it depends on how trees are rendered.
While testing eval mode, @annedino4 and I came up with a list of ideas for potential improvement. It's a long list and varied, so it's not ideal for a GitHub issue, but we should document them somewhere, so I'll create this tracking issue. As we tackle them, we can create individual issues for them and mark them here.
Not all of these are necessarily good ideas!
View the type of any node (#626)
We need to be able to click on a node in the eval view and see its type. This should probably work in the detail mode, as well.
Clicking/double-clicking detail view buttons
Assuming that the we highlight the detail view button that corresponds to the current program state in the main window (see hackworthltd/vonnegut#623 vs hackworthltd/vonnegut#622), then you should be able to click on that button to jump to that state of the evaluation. Then double-clicking it would zoom into the detail view.
Preview steps
Should we show a preview of the evaluation steps that will be taken when you select a redex? This might be helpful in understanding what's going to happen next. (It would probably be useful to allow the instructor to disable this feature, e.g., for examinations.) For example, in this situation, when I select one of the
fs in this expression, I think we should highlight thelet fand theλy.Zeroso you can see what's going to be substituted for thef:Another potential preview would be that, when you select a global variable, it shows the definition of that variable in a pop-up.
Add an evaluation "timeline"
We should have a timeline of sorts underneath the detail buttons, with a control you can grab to "scrub" the evaluation timeline back and forth, like you can do in a movie player to scrub frame-by-frame. This is basically the same as the forward and back arrows, but with a linear control.
Render all detail buttons as the same size and shape
I think the detail buttons would look nicer if they were all the same size and shape. Obviously some of them will have different amounts of whitespace, but that's better than differently-sized buttons.
AppandAPPnodes in patterns (#290)In
casepatterns, we should show theAppnode(s) in the constructor patterns, since that's what the student will see in the matching scrutinee. For example, here the scrutinee doesn't have the same shape as the matchingCons x xs1branch because the application nodes are missing in the pattern:This is not unique to evaluation mode, of course, but I think here it's most painful, because the student is likely trying to match shapes by eye.
Only the parts of the tree affected by the reduction should change shape
Tree shapes should be "stable" under rendering in eval mode. What I mean by this is that portions of a tree that are not affected by a reduction will sometimes substantially change shape, which makes it difficult to focus on just the parts of the tree that changed as a result of the reduction. This will probably be hard to do with our current rendering system. (I think we need more control of layout than our current rendering system provides, for this and other reasons.) Here's an example from an application of
map:pre-step:
post-step:
Ideally, only the
mapnode that we're reducing should change; the surrounding nodes (App,Bool,Nat, and the twoAPPs) should not move.Easy to get confused when viewing the history of the evaluation
We need a better indication to the student when they're viewing the history of the eval steps. At the moment, when the student "rewinds" and goes back a few steps, the redexes at that step are still rendered with the green outline, and it's easy to forget that you're viewing history and not the next step in the evaluation sequence, so you select a redex and it can take a few moments before you understand why the "step" button isn't highlighted. Possibly the "step" button should just disappear when you're viewing history, and/or the redex highlights should change.
Saving evaluations for future reference
It would be great to be able to save evaluations in a list somewhere in the UI. Students could go back to them for reference, compare them to other evaluations, etc.
Back button
We really need a "back" button from the evaluation mode so you can return to edit mode (e.g., to see a definition) and then return to the evaluation, without losing your steps.
Text view (limited)
@annedino4 mentioned that she'd like a text view toggle for eval mode so that she can see the text representation of each evaluation step, even if we don't implement detail steps in text view.
Inline local variable "macro" step
It might be helpful to have an "inline local variable" macro that substitutes all occurrences of the variable in the expression under the let, all at once. For example, here there are 2 occurrences of
fand it would be nice to eliminate them both in a single step:(This would be in addition to the single reduction, not instead of, because maybe you only want to reduce the one that you expect to use in a later evaluation step.)
Clicking on detail view should zoom in and out
This is pretty low priority, but it would be nice, and would help situate the student, if, when pressing on a detail button, we zoomed into the detail view, and zoomed back out when pressing the "Back" button from the detail view.