LightSOPLang Semantics
Evaluation order, value propagation, and monitoring behaviour.
Execution Scheduling
The interpreter assigns each variable to a topological level based on its dependencies. Variables without dependencies execute first. Variables that depend on others wait until their dependencies return a success status. Every time the script changes the interpreter recomputes these levels. This allows scripts to be regenerated and reloaded without restarting the runtime.
Value Lifecycle
Each variable stores a value with status, timestamp, raw output, and optional root cause metadata. When a command succeeds the interpreter compares the new timestamp and data with the previous value. If the value changed, the interpreter marks dependents as undefined so they re-execute. When a command fails, the interpreter stores a failure value and triggers the onFail handler supplied to the interpreter constructor. Undefined values propagate upstream so dependent commands wait for fresh results. Cancellation values propagate as well, carrying the original root cause so calling layers can display a meaningful message.
Auto Cancellation
The responder returned by createCommandResponder can emit cancellations. When autoCancel is enabled on the interpreter (or registry), command outputs are inspected by cancelHeuristic; strings or objects that look canceled/aborted (e.g., start with “cancel”, “stop”, or expose a status of canceled) are converted into cancellation values. The interpreter attaches the command name and heuristic details to the cancellation so dependent variables inherit the context.
English Regeneration
When the script originates from English instructions the interpreter maintains an English context object. Failed variables trigger a regeneration cycle. The interpreter collects variable snapshots and failure messages, calls the LLM with the previous code, and requests a revision. Each attempt increments a counter and stores the generated code in the context history. Regeneration stops when all variables succeed or when the configured maximum number of attempts is reached.
Execution Monitoring
The default execution monitor observes command execution counts, logs prompt regeneration, and enforces command limits. Skill families can supply their own monitor to capture audit trails or enforce stricter quotas. The monitor receives notifications before each command and when failures occur. These hooks are used in the regression suite to verify that fallback planners and English scripts behave deterministically.