Module runtime 

Runtime evaluator — walks an algebra Comprehension AST against a Lookup scope (a PolydatKernel or a Layered view) to produce typed coordinate tuples.

Why this is separate from the static IR interpreter

The static IR interpreter (super::ir::interpreter) walks a compiled stack-machine program over fully-statically- resolvable Source variants (IntRange, Literal). It has no notion of a runtime parent kernel, which is correct for the spec §9.5 consumption surfaces it serves.

Runtime comprehension evaluation is fundamentally different:

• Source-text evaluation requires the parent kernel. Source::Generator { expr: "pre_{outer}" } and Source::WorkloadParamList { name } resolve against the parent kernel’s chain — {outer} substitution via interpolate_via_kernel, kernel.lookup(name) for workload params.
• Cartesian is dependent-tuple, not independent. Clause N’s spec text may reference iter-vars from clauses 1..N-1. Prior-axis values are layered in front of the scope (Layered) so each clause evaluates against the correct context. This is SRD-18b §“Dependent Tuple Iteration”.
• Filter predicates evaluate against per-tuple scopes. Predicates in the comprehension grammar are evaluated directly against the tuple with no kernel and no compile; anything richer is interpolated against a Layered view of the scope and evaluated with eval_const_expr_for, charged to the scope’s ledger.

All three depend on polydat-side primitives that exist today; this evaluator is the algebra-typed entry point for them.

What this owns

evaluate_for_iteration is the public surface: (algebra AST + scope) → Vec<RuntimeTuple>. The returned tuples carry polydat Values, which the caller binds into a kernel over the body’s program, one per tuple.

Order modifiers route through the unified Strategy::apply (spec §10.7.8): each node returns its tuples paired with the IndexFn the materialized stream satisfies; the Order node assembles an EvaluatedInput and invokes the strategy. V4 fires at this site, definitively.

What this does NOT own

• Per-iteration kernel construction. The evaluator returns tuples; the caller binds each into a kernel over the body’s program — TraversalStream for a for statement, the renderer for a tile’s projection.

Structs

ClauseYield

Internal walker state — the scope the recursive walker resolves names against, so it does not thread it through every call. What one leaf clause yielded over a whole traversal.

EvaluatedIteration

A traversal’s tuples, and what each leaf clause yielded reaching them (ClauseYield), in the tree order of the comprehension.

Enums

RuntimeError

Errors the runtime evaluator surfaces.

Functions

evaluate_for_iteration

Evaluate a comprehension against a scope and produce the typed coordinate-tuple list.

evaluate_for_iteration_reported

evaluate_for_iteration, and what each leaf clause yielded on the way (ClauseYield).

Type Aliases

RuntimeTuple

Runtime tuple type — polydat-Value-based to preserve Ext typing (Partition / Json / etc.) through the iteration pipeline. The algebra layer’s Tuple uses TupleValue which is scalar-only; this RuntimeTuple is what the executor actually wants for per-iteration kernel binding via PolydatKernel::for_iteration.