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

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
• Documentation slide
• Statics off error formatting
• Remove parenthesis requirement for invocation
• add Livelit.md file to docs to explain to someone what they need to do to add a new livelit

Limitations of projectors, to be fixed in separate PR:

• Livelit invocation must be directly surrounded by a parenthesis

Future PRs:

• User-defined livelits (pending modules)
• Splices (pending splices in projectors)
• Parameters (pending splices)
• Pattern livelits
• LivelitAp: Switch mode of Ap to LivelitAp when applied to a LivelitName

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

[gcrois]

My understanding is that a projector's local actions currently can only modify a projector's internal model, making it impossible for a livelit to change its syntax on an update (outside of the view function) -- @disconcision is there a way to circumvent this so that the update function can change syntax? This allows a livelit to take its update functions from the context.

This is LivelitProj's update function:

let update = (_, info, action: LivelitCtx.action_exp) => {
    print_endline("LivelitProj.update " ++ Exp.show(action));

    let ctx =
      switch (info.statics) {
      | Some(InfoExp(exp)) => exp.ctx
      | _ => []
      };

    switch (get(info)) {
    | Some((llname, model)) =>
      let ll = Ctx.lookup_livelit(ctx, llname);
      switch (ll) {
      | Some(ll) =>
        let new_model = ll.update(action, model);
        let seg = info.utility.term_to_seg(Exp(new_model));
        print_endline("new segment update: " ++ Segment.show(seg));
        ();
      | None =>
        print_endline("Warning - LivelitProj.update: not found in context")
      };
    | None => print_endline("Warning - LivelitProj.update: get is empty")
    };
    ();
  };

seg is what the model segment should become, ideally

===

Update: I circumvented this by creating a callback the forwards the parent action handler, rather than the local handler -- it occurs to me that the Built-in Livelit API is strikingly similar to the Projectors API. It would be a good use of our time deciding what should be a projector vs. Built-In livelit :)

[gcrois]

https://github.com/hazelgrove/hazel/tree/livelit-lift-syntax

I attempted to replace my model replacement function with the existing lift-syntax, and ran into some errors when replacing the model -- namely, a nebulous error called "Not_found"... I had these in earlier versions of my replace model function, eventually finding stability when I replaced the labels of the existing syntax without modifying the shape or ids of the syntax.

Example:
Livelit Branch vs. Livelit with lift_syntax
When the slider livelit is projected and interacted with, model changes as expected in the livelit branch, but a fatal error occurs with lift_syntax when unprojected and selected.

@disconcision Any ideas here?

[gcrois]

We now do a full replacement of the syntax (including the livelit name). What cause the previous crash in livelit-lift-syntax is still unknown, but is resolved for now. Thanks @disconcision!

[gcrois]

Create Self.re common error type for bad livelit model, needs exp_t

For built-in livelits, we need a function to determine if an exp is a value, lives in Statics (static value checker)

[gcrois]

@cyrus- Made the changes we talked about earlier today, and a couple more for stability + error reporting