Each note follows Observation → Hypothesis → Approach → Result → Discussion → Takeaway, grounded in the documented language semantics.

Note 1 — Themed keywords over conventional ones

Observation. Keikaku replaces if/else with foresee/alternate/otherwise, for/while with cycle, def with protocol, and generators with sequence.

Hypothesis. A thematically consistent keyword set can convey construct intent while remaining learnable, if the underlying semantics stay conventional.

Approach. Map each themed keyword to its conventional equivalent and check whether a reader can predict behavior after learning only the mapping.

Result. The mapping is one-to-one and regular (foresee ≈ if, cycle ≈ loop, protocol ≈ function, sequence ≈ generator), so behavior is predictable once the vocabulary is learned.

Discussion. The theme is coherent rather than decorative, which is what makes it learnable: the keywords all draw from one planning metaphor. The cost is the up-front vocabulary lesson.

Takeaway. Themed vocabulary works when it is regular and semantics stay conventional; novelty belongs in the names, not the evaluation rules.

Note 2 — One loop keyword, three forms

Observation. cycle unifies while, through (for-each), and from/to (range) under a single keyword.

Hypothesis. Collapsing the loop constructs under one keyword reduces surface area without losing expressiveness.

Approach. Compare the three cycle forms against separate while/for/range keywords for coverage of common iteration needs.

Result. The three forms cover condition-based, collection-based, and range-based iteration, matching the common cases with one keyword.

Discussion. Unification keeps the surface small and consistent, and the through keyword is reused in generator expressions, tightening coherence. The reader learns one loop concept with three shapes.

Takeaway. A single loop keyword with explicit forms is a clean way to shrink surface area while covering the usual iteration patterns.

Note 3 — Generators as coroutines, not just iterators

Observation. sequence supports yield/proceed, delegate, and transmit/receive.

Hypothesis. Adding delegation and bidirectional communication turns generators from one-way producers into full coroutines.

Approach. Exercise the documented echo generator (receive → yield) and a maintask/subtask delegation to confirm two-way flow and splicing.

Result. transmit/receive passes values into a running generator and yields responses; delegate splices a sub-iterable’s output inline.

Discussion. This is a coroutine model, not just lazy iteration, and it is what the async layer later builds on. The bidirectional channel is the key upgrade over one-way generators.

Takeaway. Bidirectional generators plus delegation make a small language’s iteration system genuinely coroutine-grade.

Note 4 — Delegation as themed yield-from

Observation. delegate subtask() yields all of a sub-iterable’s values inline, producing start, a, b, end from a maintask that delegates subtask.

Hypothesis. A dedicated delegate keyword makes composing generators readable compared to manual re-yielding loops.

Approach. Compare delegate subtask() against an explicit cycle through subtask() as v: yield v.

Result. delegate expresses the same splicing in one keyword, matching the documented output order.

Discussion. This is yield-from with a name that fits the theme. It also accepts plain lists, not just generators, which generalizes the composition.

Takeaway. A first-class delegation keyword makes generator composition concise and readable; naming the act pays off.

Note 5 — Exception injection into live generators

Observation. disrupt(gen, error) injects an exception into a running generator at its suspension point; an in-generator attempt/recover can catch it and continue.

Hypothesis. Externally injectable exceptions let long-lived generators handle out-of-band faults without tearing down.

Approach. Run the documented robust_task/worker generators, inject a fault via disrupt, and observe recovery-and-continue.

Result. The generator catches the injected error in recover and keeps yielding, per the docs.

Discussion. Injection plus in-frame recovery is a powerful, less common feature; it treats a generator as a supervised process that can be signaled. It reuses the same attempt/recover model used everywhere else.

Takeaway. Exception injection into suspended generators, paired with in-frame recovery, enables resilient long-running coroutines.

Note 6 — Async built on generator frames

Observation. async protocol/async sequence, await, resolve, defer, and sleep sit atop the same suspendable-frame machinery generators use.

Hypothesis. An async/await layer can be built economically on coroutine frames rather than a separate mechanism.

Approach. Trace the documented main() that awaits fetch_user then fetch_posts, noting that await pauses until a promise resolves or a generator yields.

Result. await uniformly pauses on both promises and generator yields, indicating a shared suspension mechanism.

Discussion. Reusing generator suspension for async is a standard, economical design. defer and sleep supply the scheduling primitives around it.

Takeaway. If you already have suspendable generator frames, async/await is largely a scheduling layer on top; Keikaku takes that path.

Note 7 — Errors as anticipated deviations

Observation. The docs frame attempt/recover as handling “anticipated deviations in the plan,” consistent with the planning theme.

Hypothesis. Framing errors as expected deviations (not exceptional failures) encourages explicit, structured handling.

Approach. Use attempt/recover around a failing divide(10, 0) and confirm control transfers to recover error.

Result. Execution jumps to recover, binding the error, per the documented example.

Discussion. The semantics are conventional try/catch; the framing is what differs, and it aligns the error model with the rest of the vocabulary. Consistent metaphor lowers cognitive load.

Takeaway. A conventional try/catch reads naturally under the planning metaphor as attempt/recover; the framing reinforces intentional control flow.

Note 8 — The anomaly escape hatch

Observation. anomaly marks a block that “executes regardless of standard checks,” documented for intentional deviations and prototyping.

Hypothesis. Naming the act of deliberately bypassing normal control flow makes such deviations explicit rather than hidden.

Approach. Read the anomaly block semantics against the language’s emphasis on explicit, intentional control flow.

Result. anomaly is a first-class, named construct for stepping outside standard checks.

Discussion. Giving the escape hatch a name is a design statement: deviations are acknowledged and marked rather than smuggled in. It fits the theme (an anomaly is a deviation from the plan).

Takeaway. A named escape-hatch construct keeps deliberate deviations visible and intentional, consistent with the language’s control-flow philosophy.

Note 9 — ANTLR grammar plus C runtime

Observation. The stack is ANTLR (grammar), C (interpreter/runtime), CMake/Makefile (build), Shell (packaging), Python (tooling).

Hypothesis. A declarative ANTLR front end plus a C runtime is the efficient division of labor for a language whose novelty is in semantics, not parsing.

Approach. Map each stack element to its role and check that the interesting work (generator frames, injection, async scheduling) lives in the C runtime.

Result. ANTLR handles parsing; the C core carries suspension, the transmit/receive channel, injection, and scheduling.

Discussion. This keeps the parser maintainable (regenerated from grammar) and the runtime portable (C compiles across the target platforms). It is a conventional, sound implementation choice.

Takeaway. ANTLR-for-parsing plus C-for-runtime concentrates effort on semantics and keeps the interpreter portable.

Note 10 — Packaging as a first-class deliverable

Observation. The repo ships Arch (makepkg), Debian/Ubuntu/Kali (install script), and Windows (Linux → .exe cross-compile via mingw-w64) paths, plus a universal CMake build and CI.

Hypothesis. Treating installation as a first-class deliverable, not just “build from source,” is what makes a hobby language actually adoptable.

Approach. Enumerate the install paths and note the cross-compile-to-Windows-from-Linux step.

Result. Four install paths (three platform-specific plus universal) and a CI pipeline are provided.

Discussion. Cross-compiling a Windows .exe from Linux is deliberate distribution engineering, not an afterthought. It signals the language is meant to be installed and run by others.

Takeaway. Shipping a language means shipping installers; Keikaku’s multi-platform packaging is a real part of the project, not an extra.