diff --git a/conductor/tracks/intent_dsl_survey_20260612/report_v1.2.md b/conductor/tracks/intent_dsl_survey_20260612/report_v1.2.md index fcbc57ec..1e68073d 100644 --- a/conductor/tracks/intent_dsl_survey_20260612/report_v1.2.md +++ b/conductor/tracks/intent_dsl_survey_20260612/report_v1.2.md @@ -1685,17 +1685,51 @@ This subsection provides extended discussion of the 8 open questions. The main r That's 4 verbs total, plus the grammar. The placeholder track can demonstrate a round-trip end-to-end with this subset. -**Trade-off:** a larger subset (e.g., all 42 verbs) would be more expressive but harder to implement. A smaller subset (e.g., just `scan`) wouldn't demonstrate the pipeline. 4 verbs is the sweet spot. - -**Recommendation:** 4-verb minimum. The placeholder track implements these 4 verbs + the 14-primitive grammar, demonstrates a round-trip, and leaves the remaining 38 verbs for the interpreter prototype (follow-up B track) to implement. - +**Trade-off:** a larger subset (e.g., all 42 verbs) would be more expressive but harder to implement. A smaller subset (e.g., just `scan`) wouldn't demonstrate the pipeline. 4 verbs is the sweet spot. + +**Recommendation:** 4-verb minimum. The placeholder track implements these 4 verbs + the 14-primitive grammar, demonstrates a round-trip, and leaves the remaining 38 verbs for the interpreter prototype (follow-up B track) to implement. + +#### A.7.9 Question 9 — Future reservation of `arena { }` for a separate concept + +**Background.** In v1.2, the block originally named `arena { }` (per v1.0 / v1.1) was renamed to `tape { }` because "tape" better fits the *sequential data-flow* use case (per the Lottes tape-drive metaphor, the preemptive-scatter model, and the `->` pipeline direction). The rename was *not* a synonym swap — `arena` is *not* a deprecated name for `tape`. It is reserved for a different, future concept. See the term-choice note in the A.8 glossary entry for `tape`. + +**Open question:** what is the precise semantic + grammar of the future `arena { }` block, and how does it compose with `tape { }`? + +**Proposed split (Tier 1 Orchestrator's recommendation, 2026-06-12):** + +| Block | Semantic | Implementation | Tier fit | Examples | +|-------|----------|----------------|----------|----------| +| `tape { }` (current v1.2) | *Sequential data flow* — ordered placement, source-as-you-go, fits `->` pipelines and Onat's preemptive scatter | Pre-scatter at parse time; emit KYRA-style `xchg rax, rdx` boundary at entry/exit | Tier 2 (pipeline), Tier 3 (shell), Tier 4 (sandbox) | `tape { [ scan ]; [ filter ]; [ print ] }`, `tape { x := 42; y := x 2 *; use y }` | +| `arena { }` (FUTURE) | *Bulk memory allocation* — bulk-allocate on entry, bulk-free on exit, host decides lifetime, fits FFI + Jofito-style data structures | Allocate from a host `MD_Arena` (or equivalent Python `arena`); free on block exit; data is reference-stable for the block's lifetime | Tier 3 (shell/FFI), Tier 4 (sandbox-internal) | `arena { buf: Bytes := mmap 1MB; fill buf from "stdin" }`, `arena { rec: Record := open "data.json" }` | + +**Composition.** `tape { arena { ... } }` would be valid and meaningful: a pipeline stage that uses an arena-backed buffer. The two blocks would *not* be mutually exclusive — they layer. + +**Trade-offs.** +- **Pro (split):** cleaner mental model. "Tape = flow, arena = storage." Aligns with established systems-programming terminology (Jofito, Metadesk, Handmade Hero). Reserves a meaningful term for a meaningful concept. +- **Con (split):** the user has to learn two block types for what could be one with a `mode` parameter. More grammar surface. +- **Pro (unify under `tape`):** less surface area, no risk of confusion about which to use. +- **Con (unify):** "tape" doesn't carry the right meaning for bulk allocation; the metaphor breaks down. The term `arena` is too well-established in systems programming to leave unused. + +**Recommendation:** *split.* Keep `tape { }` for sequential flow (v1.2, current). Defer `arena { }` to the follow-up B interpreter prototype (or a separate v1.3 / v2.0 track). The cost of waiting is small; the cost of prematurely unifying the two concepts and having to unsplit them later is high. The current A.8 glossary entry for `tape` already documents the reservation; the follow-up track can implement the `arena { }` block without re-litigating the name. + +**Concrete next step for the follow-up B track:** define the `arena { }` grammar rule (one new line in the A.3 EBNF), the allocation strategy (Python `arena` library? a C extension? the host's `MD_Arena` if Metadesk-style FFI is added?), and at least 2-3 example uses in the A.4 verb reference. + --- ### A.8 Glossary **AI agent** — an LLM-based system that emits intent (DSL verbs) to invoke tools. The bridge script translates the intent into tool calls. Examples: Gemini CLI, OpenCode, Claude Code. -**tape** — a memory region modeled on a tape drive, declared with `tape { }`. The block's contents are pre-scattered into a contiguous buffer for efficient execution. +**tape** — a memory region modeled on a tape drive, declared with `tape { }`. The block's contents are pre-scattered into a contiguous buffer for efficient execution. + +> **Term-choice note (v1.2).** `tape { }` was deliberately renamed from `arena { }` in v1.2. The renaming decision: the Lottes tape-drive metaphor (per `X.com - Onat & Lottes Interaction 1.png.ocr.md:52-55`: *"lay out all the arguments in memory like a tape drive in the order that functions get called and source that tape at runtime for the calls"*) is a better fit for the DSL's *sequential data-flow* use case than the bulk-allocation metaphor implied by "arena". `tape` evokes ordered placement and a flow direction (matching the DSL's `->` pipeline and Onat's preemptive-scatter model); `arena` evokes a bucket. The DSL's primary verb-tier use of the block is sequential, not bulk-allocating. See Open Question A.7.9 for the future reservation. +> +> **`arena` is reserved for a future concept (do not use in v1.2+).** Per the term-choice note, `arena` is *not* a deprecated synonym for `tape` — it is reserved for a separate, future block primitive. Concretely: if the DSL grows a need for a *bulk memory allocator* (a place to stash intermediate data structures, a la Jofito's arena allocation, Metadesk's `MD_Arena`, or a future C-extension FFI block), that block would be `arena { }` and would have a *different semantic* from `tape { }`. The intended split: +> +> - `tape { }` = *sequential data flow* — ordered placement, source-as-you-go, fits `->` pipelines and Onat's preemptive scatter. Use this for: Tier 2 pipeline stages, basic blocks, lambdas. +> - `arena { }` (FUTURE, do not implement yet) = *bulk memory allocation* — bulk-allocate on entry, bulk-free on exit, with a "host decides lifetime" model. Use this for: FFI scratch buffers, C-extension intermediate storage, Jofito-style file/record data structures. +> +> The two would compose: `tape { arena { ... } }` is a pipeline stage that uses an arena-backed buffer. The current report (v1.2) ships only `tape { }`; the `arena { }` block is left as a follow-up to the interpreter prototype (follow-up B track) to define, design, and implement. See Open Question A.7.9. **bridge script** — the runtime that translates DSL verbs into MCP tool calls. The `scripts/cli_tool_bridge.py` analogue. The Application's function-calling is unchanged; the bridge is the Meta-Tooling-side runtime.