sLua: Typed Scripting for Correct Code

• sLua is a strongly typed variation of Lua that integrates formal grammar and an explicit type system to enable correctness-guaranteed code generation.
• It employs a dynamic Tree-of-Parsers that incorporates semantic context, fixed API constraints, and controlled table structures to ensure type safety and API conformance.
• Constrained decoding using non-extensible regexes and DFA-guided token filtering allows one-shot synthesis of well-formed, runtime-safe scripts for critical applications.

sLua is a strongly typed variant of Lua introduced as the demonstration language for a constrained decoding method aimed at generating semantically correct programs under a prescribed scripting API. In the reported formulation, sLua is not presented as a general-purpose replacement for Lua, but as a language and host-environment design that makes correctness-guaranteed code generation tractable by combining a formal grammar, an explicit type system, context-sensitive parsing, and decoding-time admissibility constraints. The associated framework shows that sLua programs can be generated so that they are type-correct, API-conformant, and, under additional language restrictions, runtime-correct in a host Lua engine (Li et al., 20 Aug 2025).

1. Definition and design scope

sLua is defined through two tightly coupled components: a formal specification of syntax and typing, and a generation framework that uses those specifications as hard constraints during decoding. The motivating setting is code generation for runtime-critical components, especially in domains where one-shot correctness is required. Within that setting, sLua serves as the target language through which the paper demonstrates semantically correct generation conforming to any prescribed scripting API (Li et al., 20 Aug 2025).

A central design choice is that semantic context is treated as part of parsing rather than as a post hoc verifier. The current variable-scope environment $\Gamma$, available API identifiers, and table shapes are incorporated into parser instances. This makes sLua especially suitable for constrained generation in environments where field names, function signatures, and table structures are fixed in advance. A plausible implication is that sLua is best understood as a typed scripting substrate engineered for correctness-preserving synthesis rather than as a dynamically extensible scripting language in the usual Lua sense.

2. Syntax and formal grammar

The top-level grammar refactors sLua into modular productions headed by $$\mathtt{Program} \rightarrow \mathtt{Block}\;\texttt{end\_of\_input}$$, with $\mathtt{Block}$ defined as a sequence of statements. The statement forms include local variable definitions, assignments, prefix expressions, conditional blocks, while loops, for loops, return statements, and break statements. These productions are annotated with placeholders such as $\texttt{<LOCALVARDEF\_STAT>}$, $\texttt{<ASSIGNMENT\_STAT>}$, $\texttt{<PREFIX\_EXP>}$, $\texttt{<IF\_BLOCK>}$, $\texttt{<WHILE\_BLOCK>}$, $\texttt{<FOR\_BLOCK>}$, and $\texttt{<RETURN\_STAT>}$, which mark points where child parsers are spawned (Li et al., 20 Aug 2025).

Expressions are partitioned by type. Number expressions are formed through $$\mathtt{Program} \rightarrow \mathtt{Block}\;\texttt{end\_of\_input}$$0, $$\mathtt{Program} \rightarrow \mathtt{Block}\;\texttt{end\_of\_input}$$1, and $$\mathtt{Program} \rightarrow \mathtt{Block}\;\texttt{end\_of\_input}$$2; string expressions through concatenation of $$\mathtt{Program} \rightarrow \mathtt{Block}\;\texttt{end\_of\_input}$$3 terms; boolean expressions through $$\mathtt{Program} \rightarrow \mathtt{Block}\;\texttt{end\_of\_input}$$4, $$\mathtt{Program} \rightarrow \mathtt{Block}\;\texttt{end\_of\_input}$$5, and comparison forms; prefix expressions through chained field access and optional calls; function expressions either as explicit function definitions or function-valued prefix expressions; and table expressions either as fixed-shape table literals or table-valued prefix expressions. All expression grammars are annotated with a slot $$\mathtt{Program} \rightarrow \mathtt{Block}\;\texttt{end\_of\_input}$$6 to enforce non-extensibility.

The following summary captures the principal syntactic categories.

Category	Forms
Statements	local definitions, assignments, prefix expressions, if, while, for, return, break
Expressions by type	NumExp, StrExp, BoolExp, FuncExp, TableExp, PrefixExp
Type specifications	number, boolean, string, TableName, or (\tau_1,\dots,\tau_k) -> TypeSpec

Prefix expressions occupy a special role because they mediate both field access and calls:

$$\mathtt{Program} \rightarrow \mathtt{Block}\;\texttt{end\_of\_input}$$7

with each $$\mathtt{Program} \rightarrow \mathtt{Block}\;\texttt{end\_of\_input}$$8 containing a $$\mathtt{Program} \rightarrow \mathtt{Block}\;\texttt{end\_of\_input}$$9 placeholder and an optional argument list placeholder. This structure is what later enables the framework to restrict accessible field names to those present in the prescribed API.

The grammar also explicitly encodes fixed-shape tables:

$\mathtt{Block}$0

This fixed-shape design is later used in the runtime-correctness argument. This suggests that sLua deliberately excludes open-ended table mutation patterns that are common in ordinary Lua.

3. Type system and typing judgments

The type system is presented in standard judgmental form as $\mathtt{Block}$1. The environment $\mathtt{Block}$2 records variable bindings and, by extension in the framework, available API symbols and table information. The paper gives key typing rules including variable lookup, numeric literals, string literals, boolean literals, arithmetic, numeric comparison, string concatenation, function calls, field access, function definitions, and local bindings (Li et al., 20 Aug 2025).

Among the stated rules are:

• (T-Var): if $\mathtt{Block}$3, then $\mathtt{Block}$4.
• (T-NumLit): $\mathtt{Block}$5 for any numeric literal $\mathtt{Block}$6.
• (T-StrLit): $\mathtt{Block}$7.
• (T-BoolLit): $\mathtt{Block}$8 for $\mathtt{Block}$9.
• (T-Arith): arithmetic operators require numeric operands and return $\texttt{<LOCALVARDEF\_STAT>}$0.
• (T-CmpNum): numeric comparison produces $\texttt{<LOCALVARDEF\_STAT>}$1.
• (T-Concat): string concatenation requires two strings and returns $\texttt{<LOCALVARDEF\_STAT>}$2.
• (T-Call): if $\texttt{<LOCALVARDEF\_STAT>}$3 and each argument has the corresponding type, then $\texttt{<LOCALVARDEF\_STAT>}$4.
• (T-Field): if $\texttt{<LOCALVARDEF\_STAT>}$5 and field $\texttt{<LOCALVARDEF\_STAT>}$6, then $\texttt{<LOCALVARDEF\_STAT>}$7.
• (T-Function): a function expression is typed from its parameter annotations and the return expression of its block.
• (T-Local): a local binding introduces $\texttt{<LOCALVARDEF\_STAT>}$8 into the environment for the remainder of the block.

The system is explicitly annotation-driven. Type-annotated locals and function headers enforce consistency without inference. This matters operationally because the generation framework does not need to synthesize latent type assignments during decoding; instead, it can use the declared type structure to restrict admissible continuations. A plausible implication is that the absence of type inference is a deliberate simplification that strengthens decoder-side guarantees.

4. Dynamic Tree-of-Parsers

The dynamic Tree-of-Parsers, or ToP, is the context-sensitive parsing framework used to track all semantically valid continuations of a partial sLua program. Each node in the ToP corresponds to a modular CFG template and is instantiated with the current semantic context, including the current variable-scope environment $\texttt{<LOCALVARDEF\_STAT>}$9, available API identifiers, and table shapes. The node holds an interactive LALR(1) parser for its CFG, with a current parser state (Li et al., 20 Aug 2025).

Placeholders such as $\texttt{<ASSIGNMENT\_STAT>}$0 and $\texttt{<ASSIGNMENT\_STAT>}$1 mark points where child nodes must be spawned. Each possible semantic construct with its own CFG becomes a child. In addition, whenever the CFG can accept either a placeholder or a non-placeholder terminal, a “self-copy” child is spawned to represent the alternative of staying in the same nonterminal. The tree branches therefore encode all ambiguous futures consistent with the current partial program.

The update semantics of the ToP are incremental. When a child branch can no longer parse the incoming text segment it is pruned. When one branch completes, for example because a child placeholder has been fully consumed, it is merged back up and the parent advances its parser state on that placeholder. The stated invariant is that at every step the ToP tree exactly represents the set of all parser states reachable by some completion of the partial program.

In the sLua setting, this mechanism is what turns grammar modularity into semantic control. Since parser instantiation includes scope and API information, ambiguity is not merely syntactic. It is filtered through typing and environment constraints. This suggests that ToP functions as a dynamic admissibility oracle over partial programs rather than as a conventional parser detached from synthesis.

5. Constrained decoding and non-extensible regexes

Generation interleaves an auto-regressive LM $\texttt{<ASSIGNMENT\_STAT>}$2 with incremental parsing by the ToP root $\texttt{<ASSIGNMENT\_STAT>}$3. At each step, the parser root computes a regex $\texttt{<ASSIGNMENT\_STAT>}$4 over the next segment that must satisfy the non-extensible property

$\texttt{<ASSIGNMENT\_STAT>}$5

This guarantees that once $\texttt{<ASSIGNMENT\_STAT>}$6 is matched, the stopping point for the next segment is known exactly (Li et al., 20 Aug 2025).

The decoding loop is described in three principal stages. First, generation is initialized with $\texttt{<ASSIGNMENT\_STAT>}$7 and the prompt is fed into the LLM. Second, while $\texttt{<ASSIGNMENT\_STAT>}$8 is false, the system computes $\texttt{<ASSIGNMENT\_STAT>}$9, builds a character-level DFA $\texttt{<PREFIX\_EXP>}$0 for $\texttt{<PREFIX\_EXP>}$1, and performs adaptive rejection sampling over LM tokens. Tokens are sorted by Gumbel-Top-K, and the first token with a defined DFA transition is selected. Token-healing is used to handle subword-boundary misalignment by prepending the partial token prefix and allowing a final .* in the regex. Third, the newly accepted character segment $\texttt{<PREFIX\_EXP>}$2 is fed back to the parser by $\texttt{<PREFIX\_EXP>}$3, and the root parser state advances.

The formal admissible token set at a partial program $\texttt{<PREFIX\_EXP>}$4 is

$\texttt{<PREFIX\_EXP>}$5

Constrained decoding masks the LM’s logits so that only $\texttt{<PREFIX\_EXP>}$6 remain non-zero. In sLua, this means that the next token is constrained not only by syntax but by the existence of some complete, well-formed continuation consistent with scope, types, and API members.

The paper gives an illustrative snippet for a local numeric assignment. After feeding local x: number = into $\texttt{<PREFIX\_EXP>}$7, the root’s next_regex might be

$\texttt{<PREFIX\_EXP>}$8

with an end-symbol condition. The LM may then generate 42;. After the segment is accepted, the parser advances past the <NUM_EXP> placeholder, registers $\texttt{<PREFIX\_EXP>}$9, and subsequent regexes allow only references to $\texttt{<IF\_BLOCK>}$0 or other number-typed expressions, never a string or a missing identifier.

6. Semantic correctness, API conformance, and runtime restrictions

The semantic guarantee is stated in type-theoretic terms. Because each modular CFG is enriched with type constraints and the ToP only allows terminals that preserve a derivation in that CFG, every generated statement satisfies the type judgments under $\texttt{<IF\_BLOCK>}$1. Local definitions register $\texttt{<IF\_BLOCK>}$2 in $\texttt{<IF\_BLOCK>}$3; function calls and field accesses are checked against $\texttt{<IF\_BLOCK>}$4; and type-annotated locals and function headers enforce consistency without inference. The endpoint is summarized as $\texttt{<IF\_BLOCK>}$5 (Li et al., 20 Aug 2025).

API conformance is enforced structurally. Global tables such as $\texttt{<IF\_BLOCK>}$6 and $\texttt{<IF\_BLOCK>}$7 are part of the environment, and the placeholder $\texttt{<IF\_BLOCK>}$8 in prefix expressions only allows field names present in that API’s definition. Any attempt to call or refer to an undefined API member therefore never appears in $\texttt{<IF\_BLOCK>}$9. In sLua, API validity is thus encoded as a generation-time impossibility rather than as a post-generation validation criterion.

Runtime correctness is obtained only under additional restrictions. The design disallows nil pointers by using safe callback patterns such as $\texttt{<WHILE\_BLOCK>}$0, and it disallows dynamic tables. Loops have a fixed iteration cap; recursion is prohibited or depth-capped; and function call graphs form an acyclic DAG because local functions cannot take function arguments. Under these restrictions, the paper states in Theorem 4.3 that any well-typed program must terminate without errors in the host Lua engine.

This combination addresses a common misconception that type safety alone suffices for runtime safety in generated scripting code. The formulation does not claim that arbitrary well-typed Lua-like code is runtime-correct. Instead, runtime correctness is derived from a conjunction of typing, API restriction, controlled table structure, safe callback patterns, bounded looping, and call-graph constraints.

7. Demonstration setting and significance

The reported application is the generation of game mechanics for a roguelike video game. The paper states that the method can generate semantically correct programs conforming to any prescribed scripting API and further shows, with careful design, that the semantic guarantees extend to runtime correctness in this game-mechanics setting (Li et al., 20 Aug 2025).

In that demonstration, sLua acts as the interface layer between a LLM and a host environment whose semantics are intentionally regularized. The emphasis on one-shot generation is significant: the target use case is not interactive repair after compilation failure, but direct synthesis of scripts whose admissible continuations are constrained throughout decoding. This suggests that sLua’s importance lies less in its surface resemblance to Lua than in its role as a formally tractable scripting language for correctness-guaranteed generation.

More broadly, the sLua framework combines three elements identified in the source as decisive: modular, context-sensitive CFGs arranged in a dynamic Tree-of-Parsers; a non-extensible, look-ahead regex that precisely characterizes valid next segments; and constrained decoding via DFA-guided token filtering with token-healing. In the demonstrated setting, these components yield one-shot generation of fully type-correct, API-conformant sLua scripts with strong runtime-safety guarantees in a host environment.