Orkuncakilkaya
e4265f5fdb
A registry marked `@Machine(Deer.mood)` is the transitions of a machine over that enum field of the records a state's Table<Deer> holds. Its record has from and to (the enum's variants), on: string (an action's name, "" for a transition the tick asks), guard: fn(Row<Deer>, reads...) -> bool and enter: fn(Row<Deer>, reads...) -> void; the states are the enum's variants and the start is the field's default. The rows are data (an .lres or defs), the names the studio already edits. Written by the compiler (machines.ludic, machines_write.ludic): for each action an `on` names, a row reducer in the registry's file (named ..__machine__DeerSteps, so it sits beside the program's own row reducer on the same action, after it): the row's state, the first transition from it on that action whose guard passes, the field set, enter run - guards and enters called by name. When a row leaves a state on a guard alone, `state DeerStepsMachine` (the kept row view) and deer_steps_tick(m: mut DeerStepsMachine, s: mut Herd, reads...), one transition a row a tick. Nothing allocates. The table is the whole machine: the field written anywhere else - an assignment, or a `machine` block's become over it - is a type error (check_stmt.ludic, ck_machine_write). Guards and enters take the row first, are the record's module's, keep a row reducer's rules (and may be handed the row); a guard writes nothing through it. The graph is checked, each error at its row (in the .lres when the rows are there): a state never reached from the start, a state with no way out, an `on` naming no action or an action with no @Target, a self-transition with no guard, two ways out of a state on one trigger behind an unguarded first. Also refused: @Machine off a registry, a field that is not a plain enum with a default, a @Column field, no table (or two) of the record, a transitions record of another shape, a machine outside its table's state's module. ludic schema's code section gains `machines` (registry, record, field, enum, table, start, states, actions, tick, module, at); ludic deps names a machine's reducer `reducer Deer in Herd.deer on Spook (machine DeerSteps)`. vocab @Machine; docs annot-machine, kw-machine; LANGUAGE.md "A machine as data"; examples actions/machine (+ deer_steps.lres) and ten rejects; test.ludic feat, reject and schema cases (not run); changes/machines.md. Reseeded; bootstrap-cfree fixpoint holds (317642 lines); Maroon Lake's `ludic build --check` is clean against this tree. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> |
||
|---|---|---|
| .. | ||
| assets | ||
| inventory.json | ||
| README.md | ||
Ludic documentation generator
Generates the public documentation site (the pages branch) from a single
source of truth, so the site can never drift from the language.
Source of truth
docs/
language/<category>/<id>.md one file per symbol — keyword, type, phase,
builtin, namespace method, operator, annotation
language/<category>/_section.md section title + blurb + order
language/colors/palette.json the 221 named colors (generated by `ludic-dev docs-palette`)
site/site.json landing-page messaging (hero, features, …)
site/snippets/*.ludic the code shown on the landing page (real programs)
tools/docgen/inventory.json the authoritative symbol set the coverage guard checks
A symbol file
---
id: screen-fill_rectangle # anchor + page name (screen-fill_rectangle.html)
name: Screen.fill_rectangle
category: screen
kind: namespace-method # keyword|type|phase|namespace-method|builtin|annotation|operator
tokens: Screen.fill_rectangle # literal token(s) the highlighter matches & links
sig: Screen.fill_rectangle(x, y, width, height, color)
tip: Draw a solid, filled rectangle. # one sentence — the hover-card summary
order: 1
ns: Screen # namespace-method only
member: fill_rectangle # namespace-method only
related: screen-clear screen-draw_rectangle
---
Rich description — inline `<code>`/`backticks`, "model instance" language.
Parameters: # for anything that takes arguments
- `x` — the left edge, in pixels
- `color` — the fill color, e.g. a `Color.*` name
```ludic
program Example { … descriptive-named, compilable … }
```
What it produces
One page per symbol (<id>.html), a namespace overview page per namespace
(ns-screen.html … ns-color.html), a searchable index (api.html, fuzzy
search over every symbol), the landing page (index.html), the
ludic-highlight.js highlighter (all its symbol tables, tips, per-item link
targets, per-parameter anchors and hover-card data generated from the sources
above), symbols.json, and .nojekyll.
In any code sample: keywords/types/builtins/annotations link to their page;
Screen.fill_rectangle links Screen → the namespace page and fill_rectangle
→ the method page separately; a named argument like width: links to that
parameter's anchor; Color.Charcoal links Color and Charcoal separately;
hovering any token shows a summary card from the real API data.
Build & check
The generator and its guards are written in Ludic and run through x — there is
no Python in the pipeline. assets/ (the CSS/HTML/JS templates) and
inventory.json are the only inputs the tools here still read directly.
bin/ludic-dev docs-gen --out build/pages # generate the whole site
bin/ludic-dev docs-check build/pages # coverage + duplicate-token + link guard
bin/ludic-dev check-docs # parse every ```ludic doc fence
docs-check fails CI if any symbol in inventory.json lacks a page, if a token
is documented on two pages, or if a highlighter link points at a missing page —
so "every symbol is documented, autogenerated each time" is enforced. It needs a
built bin/ludic (bootstrapped from the IR seed with clang alone).
Publish
.forgejo/workflows/docs.yml bootstraps the toolchain from the IR seed and runs
ludic-dev docs-gen + ludic-dev docs-check on every push to main that touches docs/**,
tools/docgen/** or tools/ludic-cli/**, and publishes the result to the pages branch
root. index.html + .nojekyll always stay at the root.
Colors
palette.json and selfhost/backend/stdlib/emit_color.ludic are both generated
by bin/ludic-dev docs-palette from a single palette table — the pal_add(...) rows in
tools/ludic-cli/docgen.ludic. Edit the table there and regenerate; do not hand-edit the
generated files.