Hazel HTML

[disconcision]

Elm-style web apps as Hazel programs. Write a 4-tuple (init, update, view, subs) anywhere in a program, project it, and it runs:

type Action = Int in
let update(model: Int, action: Action): (Int, Cmd) = (model + action, CmdNone) in
let view(model: Int): HTML =
  Div([], [Button([OnClick(1)], [Text("+")]), Int(model)]) in
(0, update, view, fun _ -> SubNone)

Editing update while it runs rebinds the live app and keeps its state, as long as the new view still accepts the old model.

HTML, Attr, Cmd, Sub and KeyEvent/MouseEvent are builtin types; HazelDOM renders values of them to vdom. App state lives in AppStore, an id-keyed store in page state rather than in the syntax — models hold closures, and SetModel is an edit action, so putting it in the tree would mean whole-document statics per message. Dispatch is is_edit=false and non-historic, so clicking a button doesn't touch statics or undo.

The model comes first in update, matching fold_left's (acc, elem) and Hazel's subject-first convention, so update folds directly over a list of actions. update always returns (Model, Cmd); a program that issues no commands can return a bare Model and lift it with a two-line noCmd at the tuple, which keeps the 4-tuple's shape uniform. (The runtime tolerates a bare model via a warning fallback, but relying on it would put two update types through one slot.)

There is one HTML projector, not two. It picks its commit target per render from the projected expression's live value: a 4-tuple gets state commit, where the model lives in AppStore; bare HTML gets syntax commit, where the expression itself is the model and an action is an Html -> Html transform spliced back in. So "self-modifying HTML" is not a separate feature, just what the projector does when handed HTML — and it only works on closed HTML, since evaluation erases variables before the splice.

To facilitate displaying HTML apps alongside code, all projectors gain a generic placement toggle (Inline | Sidebar): Alt+S on any projector docks it to a new Projectors panel, leaving a chip at the code site.

Ten example apps in hazel-programs/mvu/, each also shipping as a documentation slide under MVU / … with its app already running and docked. regen-slides.sh re-encodes the slides from the .hz sources; nothing detects a stale encoding, so that script is the only correct way to edit them. The generated slides in src/mvu/ are most of this PR's diff — ~54k lines, in line with the existing src/b2t2 (5.8 MB) and src/web/init/docs (1.3 MB) slide libraries.

Also here because the ~50-variant recursive builtin types made it necessary: ConstructorMap.venn_regions was O(n^2), builtin constructor annotations now stay in compact Var form instead of expanding, and physical-equality fast paths were added to Typ.meet/normalize/Equality.

docs/mvu.md is the feature doc: program shape, the type and event reference, the design decisions and the known limitations.

Known caveats: init accepts any Var/Ap (the value can only be checked after evaluation), so the HTML context-menu entry offers itself broadly; AppStore.gc is implemented but unwired; the Projectors panel shows only the reported editor's projectors; subscriptions are torn down and recreated on every model change, so timers restart their countdown each tick. Opening a slide shows the code plus a chip, and the app appears once the Projectors panel is revealed — the panel choice then persists, so that is one click per browser profile rather than per slide.

Not caused by this branch but worth flagging, since interactive apps make it visible: an MVU dispatch is dominated by IncrEval.remove_pat_bindings (~50%) and UUID minting during evaluation (~30%). Measured, with a writeup, but untouched here.