Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

RFD-0005 — One grammar, multiple evaluation contexts

Committed Opened 2026-05-03 · Committed 2026-05-03

Question

Argon admits expressions in many situations: declaring concepts, computing derived values, querying state, mutating state, asserting tests, building diagrams, framing hypotheticals, exemplifying in doc-tests. Should each situation have its own sublanguage, or one shared expression grammar evaluated under different contexts?

Decision

One grammar. The same expression grammar serves the declare / compute / query / mutate / test / diagram / hypothetical / doc-test contexts. What differs across contexts is the evaluation semantics — what an expression means in declare-context (a structural assertion) versus query-context (a Prolog-style retrieval) versus mutate-context (a side-effecting transition). The grammar does not change.

The context system is extensible. Adding a new evaluation context (a future workflow primitive, a new meta-reflection mode) does not require a new grammar; it requires a new context-evaluation rule.

Rationale

Sublanguages multiply learning surface. A user who has learned how to write a derive rule has also learned, almost for free, how to write a query, a mutation, and a test assertion. Each context-specific extension would have re-introduced the cost of learning a new syntax for the same conceptual machinery (binding variables, navigating relations, applying predicates).

Context is what shifts, not syntax. A predicate married(X, Y) is the same syntactic shape whether it appears as a fact assertion, a rule body, a query head, a test expectation, or a hypothetical premise. The semantics of “what this means right now” is determined by the surrounding block. The reader’s mental model is “what context am I in” once, then everything inside is the same language.

Evaluation contexts are first-class and composable. Test contexts can nest queries. Hypothetical contexts can nest mutations. Doc-test contexts evaluate compute calls. The shared grammar is what makes nesting work: the inner context inherits the outer’s variable bindings without re-parsing.

Consequences

  • Adding a new evaluation context (e.g., simulation { … }, replay { … }, future kernel primitives) is a context-evaluation extension, not a grammar extension. No tree-sitter changes; no new keywords beyond the context’s introducer.
  • The compiler classifies each expression’s evaluation context during elaboration. The same Core IR atom may evaluate differently depending on the surrounding block.
  • Diagnostic codes like OE0211 (assertion-consequence-unlowerable) attach to the expression-in-context, not the expression itself. An expression that’s valid in query-context may be invalid in declare-context with a clear, context-specific diagnostic.