ed/manual_slop
Private
Public Access
0
0
Fork 0
Code Activity

conductor(track): Annotate tape/arena term choice in A.7 + A.8

Browse Source 
Two annotations added to v1.2 of the report:

1. A.8 Glossary 'tape' entry now has a term-choice note (v1.2) that
   documents:
   (a) The rename rationale: 'tape' fits the sequential data-flow use
       case (Lottes tape-drive metaphor) better than 'arena' (which
       implies bulk allocation).
   (b) Explicit reservation of 'arena' for a future, separate concept
       (NOT a synonym for tape). The two would compose:
       tape { arena { ... } } is a pipeline stage that uses an
       arena-backed buffer.
   (c) The intended semantic split:
       - tape { } = sequential data flow (pre-scatter, source-as-you-go)
       - arena { } (FUTURE) = bulk memory allocation (bulk-allocate,
         bulk-free, host decides lifetime)

2. A.7.9 New Open Question 9 added: 'Future reservation of arena { }
   for a separate concept'. Documents:
   - Background: the v1.2 rename was not a synonym swap; 'arena' is
     reserved for a different, future concept.
   - Proposed split with a comparison table (semantic, implementation,
     tier fit, examples).
   - Composition: tape { arena { ... } } is valid and meaningful.
   - Trade-offs: pro/con of split vs. unify; recommendation is split.
   - Concrete next step for the follow-up B track: define the arena
     grammar rule, allocation strategy, and 2-3 example uses.

These annotations close the loop on the term-choice discussion. The
follow-up B track (interpreter prototype) can now implement the
arena { } block without re-litigating the naming.
This commit is contained in:
Edward R. Gonzalez
2026-06-12 11:15:14 -04:00
parent cbe65b3f71
commit 7105f75756
1 changed files with 39 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files
conductor/tracks/intent_dsl_survey_20260612/report_v1.2.md
+39 -5
View File
@@ -1685,17 +1685,51 @@ This subsection provides extended discussion of the 8 open questions. The main r
- **2 Tier 2 verbs:** `scan` + `filter` (the minimum pipeline)
- **1 Tier 4 verb:** `sandbox` (the IEventTarget boundary)
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.
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.
#### 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.
**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.
> **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.