Yichus

Example

← Lenses and diagrams

PROGRAM ORGANIZATION / FORUM

Explore a program’s organization.

When a feature changes several handlers, where should that change live? Explore this forum’s request handlers and shared building blocks. Open a group, follow its references, and compare two ways to extract repeated response construction.

The program is written in Bosatsu. Yichus compiles it and extracts the references shown here. The grouping is an author’s explanation; the arrows are checked against the compiled program.

Freeze a version, then edit the program or choose a candidate to compare the same question and handlers. Use Show paths for indirect references. Select a definition to focus its direct neighbors or download its evidence.

The editor and Run use the current program version. The before snapshot is a frozen record for review.

Loading the recorded map. The browser compiler starts only when you rebuild or run.

Try an extension before choosing an abstraction

The current program constructs the same thread envelope in read_thread, post_reply, and edit_post. The two candidates extract that construction: one returns a complete Response; the other returns fields that a caller can extend.

  1. Add has_replies at the top level of those three successful responses, based on the returned post list.
  2. Add fresh_reply_id only to the successful reply response. Keep the other responses unchanged.
  3. Add member_count inside every serialized Thread. Inspect render_thread first: the existing abstraction already covers this change.
  4. The preview extension reuses validation, visibility, capacity checks, reads, and shared fields to show the current thread without allocating an ID or writing a post. Compare its direct effects with post_reply.

Compare the places each change would touch. The candidates preserve the existing envelopes; they are experiments in interface design, not a claim that production needs a refactor.

Read or edit the program and its grouping

The source and grouping are editable. Rebuild checks both. Editing invalidates the displayed map immediately. Group labels and the comparison question remain authored descriptions, even when their binding references resolve.

Automatic ordering tries to reduce crossings and sideways detours. To override peer order, add an order array to view.json with entries such as "group:representation" or "node:Yichus/Examples/Forum::respond". The dependency bands remain.

For definitions moved between packages or renamed, correspondence.json accepts an array such as [{"before":"Old/Package::name","after":"New/Package::name"}]. Both identities must exist in their respective snapshots, and each may appear once. This records the author’s correspondence; it does not prove equivalent behavior. Grouping changes are shown separately from definition and reference changes.

Run uses an in-memory forum with one members-only thread, Bob as the reader, and one existing post. It executes the edited program. Your agent can change the handler, inputs, and rows through the example tools.





What the map establishes



An arrow to can_see does not establish that a permission decision protects an operation. The separate access analysis checks the rules declared in the source. Forum’s post policy accepts either can_see or can_edit; a passing result is not a guarantee that both were required.




↻ identifies a compiled loop or recursive function contained in a definition. Group size follows the space needed for labels and expansion; it does not encode quality or complexity. Vertical position follows grouped references, not conceptual abstraction levels. This is distinct from nested groups: an author can group ordinary non-recursive code recursively. Types and dependencies on platform packages are outside this user-definition reference map.

Download the source, authored view and checked artifact





Where this fits
What this is about: Lenses and Diagrams
See it
Learn it
Do it