Use Editor code to show outputs as well as inputs #1297
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Editor Componentization
Motivation:
The goal of this refactor is to turn Haz3lWeb into a series of re-usable components. There is both a short-term, and long-term motivation to do this:
In the short-term, being able to re-use the editors, and statics highlighting in particular will allow us to select / edit outputs. This is important for the interactions that will be in the proof stepper but also for the flexibility to copy results back into code etc.
In the long-term, this componentization gets us closer to good coding practices in the hazel codebase. It creates a separation of concerns where each component can consider only its local state/updates, instead of needing to worry about global state/update.
Strategy:
Each component is a file that contains four modules:
Old Description:
Motivation:
Currently there are two different ways to print code on a screen, 1) the editor for editable expressions and examples, 2) the pretty printer for outputs. In this PR we want to use (1) to print both, this will allow us to select / edit outputs in future PRs (which will be particularly useful in proofs)
The main complexity this PR adds is that there is no longer a flat fixed list of zippers, but there can now be any number of zippers in a stepper or in results too. We solve this by creating a selection type that specifies where within the model the
Implementation Strategy
I'm currently imagining a two-step process:
For (2) we can borrow a lot of ideas from the current pretty printer
Progress
Converting outputs back to editors
Recreate the old stepper in this system
Current bugs
All of these print weirdly:
6/0
{6/6}?$$?
{? ? ?}0.000000000000000000001
{1e-21}()
{split_kids index out of bounds}let (a,b,c) = (1,2,3) i
{invalid argument List.map2}(fun (a,b) -> ?)(1,_
{invalid argument List.map2}test 1
{Unhandled exception}1::
{invalid argument List.map2}[1,2,3]@[4,5,6]
{invalid argument List.map2}check that I haven't broken: