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.
Properties
Section titled “Properties”anonymousBodies?
Section titled “anonymousBodies?”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.
constants?
Section titled “constants?”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.
frozen?
Section titled “frozen?”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
Section titled “hasAsync”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
Section titled “numbers”numbers: Float64Array;Defined in: packages/engine/src/parser/BytecodeBuilder.ts:46
opcodes
Section titled “opcodes”opcodes: Uint8Array;Defined in: packages/engine/src/parser/BytecodeBuilder.ts:45
pluginCalls?
Section titled “pluginCalls?”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
Section titled “strings”strings: string[];Defined in: packages/engine/src/parser/BytecodeBuilder.ts:47
userFunctionBodies?
Section titled “userFunctionBodies?”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.