Agenda: Matthew and Cyrus, Wednesday 2026-10-21

3. Livelits' model views as read-only tiles, with the tiles' selection UX both gaps fixed, seen in the app #3 copy item

Asked by Cyrus, 2026-10-16 · ^ticket(387) · as of 2026-10-20 22:37

^report(19): a livelit's model, revealed with its eye, is the one view outside the editor that already has read-only tiles with a caret, Shift+Arrow selection, the inspector and the right-click menu. Two gaps, seen on #2635: a mouse drag over the model selects by character, not by tile (its ends do not snap to tiles, as they do in the editor); and while the revealed model has focus, the rest of the editor draws blank until the eye closes. A livelit's head and params lines are HTML inputs, by design.

Both gaps fixed (2026-10-19, on #2635 as 1b7a03e8e5 and #2597 as 54e5a66bf2, ^ticket(387)): a drag inside the model's splice had been hardwired to go by character; it now goes by tile, as in the editor, unless character-level mouse is on (a new test, Editing.Splice 16). And the code view's memo had lost its frame argument in a merge, so the model's sub-editor and the editor shared one cached drawing, and the editor drew the model's rows; the argument is back. Seen in the app (2026-10-20) on #2635's build: on Editable Parameters, with the baseline slider's model revealed, a drag across pct=50 selects whole tiles, a drag inside baseline takes no stray letters (the inspector names the variable), and the editor stays drawn while the model has focus.

For the meeting: Is the revealed model's read-only selection what Cyrus wants on every look-only view? ^report(19) suggests one shared read-only, selectable view for all 16 of them.

4. The explainer's examples as read-only tiles queued #4 copy item

Asked by Cyrus, 2026-10-16 · ^ticket(388) · as of 2026-10-19 12:30

^report(19): the examples are already tiles, in a locked cell editor. They take focus but no caret, no selection and no menu. The inline code in the explanations is plain text. So, as with the model views, the ask comes down to selection and the menu.

For the meeting: The same question; and should the inline code become tiles too?

12. How long each documentation slide takes to open, timed on GitHub measured on both PRs #12 copy item

Asked by Matthew, 2026-10-20 · ^ticket(470) · as of 2026-10-20 22:37

Matthew asked for the time to open every documentation slide, each livelit slide among them, on GitHub's machines rather than his, what dominates each one's cost, and to keep tracking it with the performance PRs applied. A job on a branch of each PR opens every slide in headless Chrome, each in a fresh tab with its saved state cleared, and records when the page stops changing, with a CPU profile of the page and of the eval worker. Each profile's time in js_of_ocaml's runtime and the OCaml libraries is charged, through the source maps, to the nearest Hazel function that called it.

#2635 (run 39524173735, today): all 58 slides open and settle, 264 s in all. Most take 2.7 to 3.4 s. The slowest are Dynamic Row or Column (12.5 s, parsing 45% of it; 4.2 s on #2597), the playground's Witch (12.1 s) and Full Body (12.0 s), the perf-mega-4k stress slide (11.3 s), Scenes (9.9 s) and Shoes (8.3 s). The figure slides are two-thirds to four-fifths page script (Shoes 6.2 of 8.3 s, Full Body and Witch 9.7 of 12 s); alongside it, the eval worker runs 2.8 to 3.6 s (4.8 s on Full Body and Witch, 5.5 s on Scenes).

Where the time goes, over all slides (213 s of script, charged to the nearest Hazel caller): the view 55 s, terms 45 s, parsing 41 s, statics 23 s, layout 13 s, evaluation 10 s, the runtime with no Hazel caller 14 s, projectors 4 s. Most slides are mixed, the view first (30 to 40%) and parsing second. The Hazel functions charged with the most library time: TermBase.re 11.1 s, Main.re 6.5 s, ConstructorMap.re 4.5 s, and the worker's own bookkeeping, WorkerMetrics.re 4.3 s and WorkerServer.re 6.2 s.

#2597 (run 39524190956, today; its previous run, 39482019681, had lost the one slide after Witch, Scenes, to a DevTools call that never answered, and the job now records such a slide and goes on): 52 of its 55 slides open and settle, 479 s in all. Most take 2.2 to 2.9 s, as on #2635. The playground's figure slides do not: Shirt and Pants 35 s, Hair 40 s, Arms 40 s, Mouth 42 s, Eyes 48 s, Hands 59 s, Shoes 71 s (on #2635, 6 to 8 s each); Full Body and Witch are still not open at the 3-minute limit, and Scenes keeps the page too busy to answer past it.

Where #2597's time goes (362 s of script): statics 143 s, parsing 83 s, terms 81 s, the view 32 s. On the figure slides statics is about half, terms a quarter, parsing a fifth; ConstructorMap.re alone is charged 45 s (4.5 s on #2635), then LabeledTuple.re 19 s, Skel.re 13 s and Form.re 17 s. #2635 carries #2469's statics work, which #2597 does not; that is most likely most of the difference.

On Matthew's laptop, Scenes's evaluation times out on #2635's build too, so its livelits do not draw at all there.

For the meeting: Whether to keep the job on both PRs and on dev, so each PR's effect on opening times shows; whether #2597's figure slides (35 to 71 s, two not opening at all) are worth fixing on #2597 itself or only through #2635; and on #2635, which to take first: parsing on the slowest slide, the view's share on every slide, or the worker's bookkeeping, about 10 s over the 58 slides.

13. Hazel tiles for a game's logic: Messed Up Dress Up as a Scratch-like world ideation, measured; a first demo built #13 copy item

Asked by Matthew, 2026-10-20 · ^ticket(473) · as of 2026-10-20 22:37

An idea, partly Matthew's to shape. Livelits show Hazel can express a great deal, but not yet fast enough to be a game's engine or its drawing. The game's logic is another matter, especially simple event declarations: when this happens in the game, queue that action, perhaps at once. Hazel tiles inside Messed Up Dress Up, customizing its behavior over its world, people and objects, would make each drive the other: more play, and more research. Such rules are small and run seldom next to the game's frames, so they fit Hazel's evaluator as it is.

Against Languages of Play (Martens and Hammer, 2017; HTML). The paper treats each game's interface as a programming language of player intent: its syntax the intents the game recognizes, its operational semantics the mechanics as inference rules for a step from a state and an intent to a new state and a response, its type system a contextual interface in which only what makes sense in the current state can be said; play traces are straight-line programs, and player skills general ones, with branching on the game's response, parameters typed by the resources they need, repetition and parallel composition, which it offers as a scripting language for modding and co-creative play.

• Where they meet: "when this happens, queue that" is the paper's skill as a program, made reactive: a rule fires on a game event rather than being issued by the player, and its body is the same shape as the paper's do-then-case-on-the-response.
• Where the paper goes further, and Hazel could follow: Dress Up's intents (walk, climb, sit, open, pull a lever, dress) as a typed syntax; the context (where the friend is, what is near) as the rules' type system, so a rule that can never apply is a type error rather than a silent no-op; the mechanics as inference rules, which Hazel can already hold as derivations, with the paper's "never gets stuck" as a property checked where the rules are written; play traces as structured values to query, as Hazel's probes already are.
• What Hazel adds that the paper only anticipates (it cites Hazelnut): rules that are meaningful while half-written, with holes; the game's own controls inside a rule, as livelits (a slider for a jump's height, a picker for a place); and proof beside program in one editor.
• Steps, smallest first: the events and intents as a Hazel sum type; rules as Hazel values the game reads into its queue; the context as types; traces the game logs as values Hazel can query; later, mechanics as inference rules.

Measured (^ticket(402), on #2635's code, the test build under node on a GitHub runner): a lever pulled flips every trapdoor a table of lever-to-trapdoor links names, written in plain Hazel, and again monadic (the rule returns commands as data, which a game would interpret against its globals, as Matthew asks: "we need global variables for simple games --- most scripts use them"). Statics and elaboration, once: 8 to 70 ms. Per pull: 0.7 ms with 10 links (0.95 ms monadic), 5.7 ms with 100, 65 ms with 1,000: linear in the table, since a list is scanned each pull. A trap room is a few links, so a twentieth of a 60-frames-a-second frame; drawing is what Hazel cannot do in time yet. The monad itself, $GameUpdate, with variables named by Fumola-like symbols, is ^ticket(479).

Sketched (^ticket(479)): the trap room's lever as a $GameUpdate program, a monad beside livelits' $UpdateCmd, its commands run by the game and each awaited (a walk takes time; the program resumes after), the game's variables named by typed, Fumola-like symbols:

# $GameUpdate: commands the game runs, each awaited, with do as for $UpdateCmd #
#   pure(a)          | get(@sym) / set(@sym, v)  the game's variables, by symbol #
#   walk_to(@thing)  | anim(name, ms) | wait(ms) | emit(event)  queued, e.g. Fell(pit) #
# A symbol is a pointer into the game's saved state, typed by what it holds: #
#   @room.lever(L) : Sym(Bool), @room.wiring : Sym(Wiring), @access.lever_far : Sym(Bool) #

let pull_room_lever = fun side : Side ->
  do far <- get(@access.lever_far) in
  do _ <- (if far then pure(()) else walk_to(@room.lever_thing(side))) in
  do up <- get(@room.lever(side)) in
  do _ <- set(@room.lever(side), !up) in
  do _ <- anim("lever-turn", 1400) in
  do wiring <- get(@room.wiring) in             # normal, reversed or random #
  do opened <- swing_pits(pits_worked(wiring, side)) in
  do at <- get(@friend.place) in
  if over_any(at, opened) then emit(Fell(at)) else pure(())
in

In the game today that is about 150 lines of JavaScript (the room's levers, its boulder levers, the placed levers' links, the walk to a lever and the pull, the pits' wiring). In Hazel, by estimate: the rules 60 to 90 lines; the monad's declaration in the builtins, as $UpdateCmd's is, 40; and in the game a command interpreter, about 100 lines of JavaScript, which keeps every animation and walk where it is now. Per pull, ~1 ms of Hazel (as measured above), the animations' time aside. What is new to Hazel: commands that suspend for the game, and symbols as typed pointers into a store Hazel does not own.

What it would take (^ticket(480)) for a Scripting panel in Dress Up, an editor per room, starting with the castle's dungeon:

1. Hazel as a JS library, a second build entry beside the app's: analyze(text) and evaluate(text) on the page's own thread (rules this small need no worker), then mountEditor(element, {text, onChange, ...}), one code editor in any page. The editor assumes the whole app today (its settings, focus handling and keys at the document, its stylesheet unscoped), so that is the main work; and Dress Up's own keys move the friend, so keys must stay in the editor that has focus. About 7 MB of script, loaded only when the panel opens.
2. One global program, composed from the panel's editors: module Common = {...} in module Dungeon1 = {...} in ..., each room's editor a module named by its room, Common in scope in all of them; Dress Up makes the names (and refuses a duplicate). #2469's modular editors, which #2635 carries, already show one program as a cell per definition: the closest start.
3. The $GameUpdate monad (sketched above) as a builtin, and its interpreter in the game.
4. The hook: on an event (a lever pulled, a room entered), the game asks the program's handler for that room and runs the commands it returns.

Order: 1's analyze/evaluate and 3 first, with the rules in plain text, which runs the dungeon's logic end to end; then the editor, then the panel.

Built since (2026-10-20): Hazel as a JS library, a draft PR (#2711, ^ticket(481)): Hazel.run(text) returns a program's errors and its value as plain JS, a Hazel function as a JS function. And a 🧩 Scripting panel in Dress Up, a PR of its own (^ticket(482)): an editor per room, and the castle trap room's red levers run by its rule, on_event : (Globals, Event) -> Cmd, a command tree the game interprets. Tonight a bug in the library kept a rule with an ascribed parameter stuck on an event sent from the page (a constructor from JS had no type, so the parameter's ascription could not go through it); fixed on #2711, with tests. hazel.org now serves the fixed build, and #2711 is green on Fast checks and Full tests; with it the demo's levers work in the game on the Scripting panel's branch (kids-choice-games PR #1, not merged: the published game does not have the panel yet): a pull runs the trap room's rule, and the rule's command flips the lever. Still open, for Matthew: a constructor from the page with no value, whose tag the parameter's type lacks, is not refused at the ascription; a check for that is built and tested on a local branch, not pushed.

For the meeting: Whether this is worth a direction; which of the paper's layers to show first (typed intents and contextual types look nearest); and what is Matthew's to decide: which events and actions first, where the tiles sit in Dress Up, and who writes rules (M and N among them).