Livelits

[gcrois]

This merge brings a implementation of Livelits, proposed by https://hazel.org/papers/livelits-pldi2021.pdf, with some built-in examples.

Examples:

1. Emotion
2. Timestamp (Can't keep up)
3. Slider
4. JS (Can't save result?)

Issues:

• Look up livelit in the context
• Show the livelits in scope in the context inspector
• Livelit names are showing errors
• When you press space after a livelit name, it should initialize the model argument
  • and turn on the livelit projector immediately
• Only displaying correct view in smiley face projector every other update (may also affect other livelits?)
• ExplainThis sidebar should show information about livelit applications when relevant
• Create a documentation slide showing how livelits work
• Separated browser tests and URL encoding (currently they are already merged in here)
• Backspace should break projection, remove default model
• Fix livelit ap term -- consider modifying MakeTerm (similar to deferred Ap)
• Unbound livelit error state
• ExplainThis colorful formatting
• Documentation slide

Limitations of projectors, to be fixed in separate PR:

• Livelit invocation must be directly surrounded by a parenthesis

Future PRs:

• User-defined livelits
• Splices
• Parameters
• Pattern livelits

1. Cannot define Livelits during runtime, Livelits don't have access to context -- this needs to be revealed to projectors
2. Cannot implement splices, requires context, merge with Live Projectors ? @disconcision
3. Livelit invocation must be directly surrounded by a parenthesis in order to be grouped in InfoExp; example: (^emotion(100)) -- this is a current limitation of projectors

[cyrus-]

One issue right now is that type errors on livelit projections aren't displayed, because the type error is located on the livelit ap underneath the parentheses. @disconcision any thoughts on what we should be doing here? I think in general I'd support shifting the indicators for type errors at the root of a parentheses to the parentheses (while still showing the error message when your cursor is on the parenthesized term as well). Maybe that general change would address this problem too?

[disconcision]

@cyrus- i've been thinking about this one, or more generally the issue of what to do when there is a 'deep' type error that will be hidden by a projector. i think it's worth considering a more general solution, where if there is an error under a projector, meaning an error strictly inside the underlying syntax which is not inside a splice, then we place a new kind of error/warning on the projector itself. but I'm not sure about how this should be surfaced in the cursor inspector. also i think this might be worth considering in tandem with a broadened notion of error provenance/attribution, which provides at least some kind of indication that an expression contains / is downstream of some kind of error or incompleteness. this doesn't have to be as aggressive as a red outline; perhaps a tag in the cursor inspector.

i've also thought about the parentheses thing as an interim solution. as you point out there are subtleties (also wanting the error on the contained term), meaning it's not as simple as just changing parentheses statics. so yeah certainly possible to do something here but i think it's worth whiteboarding some options or at least dedicating a lunch to the short and mid-term future of error attribution

[cyrus-]

yeah let's discuss this (+ rewriting) at lunch on Wednesday

[gcrois]

Two things came up when trying to finish this off:

hazel/src/haz3lmenhir/Conversion.re -> What should we do here w.r.t. of_core (line 511)? @7h3kk1d Maybe you have insight?

You can backspace and space to unproject / reproject the livelit, but if you change the state, you can't do navigate using arrow keys, or insert characters until you click somewhere -- I suspect this is a problem with how I remove projectors in hazel/src/haz3lmenhir/Conversion.re line 277, maybe I am supposed to change the left and right somehow?