Skip to content

This site describes solve-engine as it is on main: 2.43.0, which npm does not have yet. npm installs 2.40.0, so a page may show an answer that version does not give yet.

BytecodeProgram

Defined in: packages/engine/src/parser/BytecodeBuilder.ts:44

Compiled bytecode program produced by BytecodeBuilder. Ready for consumption by executeBytecode without further processing.

optional anonymousBodies?: AnonymousBodyDef[];

Defined in: packages/engine/src/parser/BytecodeBuilder.ts:93

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.


optional constants?: Map<number, number>;

Defined in: packages/engine/src/parser/BytecodeBuilder.ts:58

Numeric constants by opcode position, restored from a snapshot.

Nothing in the compile path writes this: numbers are emitted inline into numbers instead. build() used to attach an empty Map to every program anyway, which was one allocation per compiled expression, around a tenth of parse-and-compile time, for a collection that was never read. It is left off now, and only EngineSnapshot sets it when restoring a program that carried one; every reader already guards on its absence.


optional frozen?: FrozenDirective;

Defined in: packages/engine/src/parser/BytecodeBuilder.ts:103

Present when the line ends in frozen (or frozen on <day>): the key its answer is stored under, the day it names, and the variable it defines.

Set by the engine after the rest of the line compiles, never by a parselet, and read by executeBytecode, which answers from the engine’s frozen store instead of running the program whenever it can. Carried in a snapshot with the program. See vm/FrozenValues.ts.


hasAsync: boolean;

Defined in: packages/engine/src/parser/BytecodeBuilder.ts:65

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: Float64Array;

Defined in: packages/engine/src/parser/BytecodeBuilder.ts:46


opcodes: Uint8Array;

Defined in: packages/engine/src/parser/BytecodeBuilder.ts:45


optional pluginCalls?: {
at: number[];
names: string[];
};

Defined in: packages/engine/src/parser/BytecodeBuilder.ts:74

The plugin functions this program calls, by name, and where each call’s index bytes start in opcodes. A plugin function’s index depends on which packages are registered and in what order, so anything that must identify a program across engines (the seeded random key, see engine/SeededRandom.ts) and a snapshot restore (#658) read the names instead. Absent when the program calls none.

at: number[];
names: string[];

strings: string[];

Defined in: packages/engine/src/parser/BytecodeBuilder.ts:47


optional userFunctionBodies?: UserFunctionDef[];

Defined in: packages/engine/src/parser/BytecodeBuilder.ts:83

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.