BytecodeProgram
Defined in: packages/engine/src/parser/BytecodeBuilder.ts:19
Compiled bytecode program produced by BytecodeBuilder. Ready for consumption by executeBytecode without further processing.
Properties
Section titled “Properties”anonymousBodies?
Section titled “anonymousBodies?”optional anonymousBodies?: AnonymousBodyDef[];Defined in: packages/engine/src/parser/BytecodeBuilder.ts:49
Anonymous function bodies compiled alongside this program, one entry
per map/reduce inline transform expression (e.g. the 10*x in
map(10*x, [0,1,500])). See BytecodeBuilder.emitAnonymousBody.
Deliberately a SEPARATE side-table from userFunctionBodies, not
routed through vm.userFunctions at all: an inline body has no name
and must never leak into the persistent name-keyed registry the way
a real f(x) = ... definition does.
constants?
Section titled “constants?”optional constants?: Map<number, number>;Defined in: packages/engine/src/parser/BytecodeBuilder.ts:23
hasAsync
Section titled “hasAsync”hasAsync: boolean;Defined in: packages/engine/src/parser/BytecodeBuilder.ts:30
Whether the program contains any async opcodes (CALL_PLUGIN, etc.).
Set during compilation by the BytecodeBuilder. Allows the engine
to skip the O(n) resolver preflight check in O(1) for purely
synchronous expressions like 2 + 2.
numbers
Section titled “numbers”numbers: Float64Array;Defined in: packages/engine/src/parser/BytecodeBuilder.ts:21
opcodes
Section titled “opcodes”opcodes: Uint8Array;Defined in: packages/engine/src/parser/BytecodeBuilder.ts:20
strings
Section titled “strings”strings: string[];Defined in: packages/engine/src/parser/BytecodeBuilder.ts:22
userFunctionBodies?
Section titled “userFunctionBodies?”optional userFunctionBodies?: UserFunctionDef[];Defined in: packages/engine/src/parser/BytecodeBuilder.ts:39
User-defined-function bodies compiled alongside this program (one
entry per name(params) = body definition on this line). See
BytecodeBuilder.emitUserFunctionBody. OpCode.DEFINE_USER_FUNCTION’s
operand is an index into this array, resolved at VM-execution time
(not parse time) so a diagnostic/lookahead parse that never actually
executes the definition line has no side effect on vm.userFunctions.