GocciaScript is a FreePascal implementation of ECMAScript with sandbox-first recommended defaults and opt-in compatibility/runtime surfaces. This glossary is the canonical language for project-specific terms used in code, docs, issues, and reviews.
GocciaScript: A sandbox-first ECMAScript runtime and toolchain for AI agents, with an explicit host-defined capability model and generated test262 evidence. It is implemented in FreePascal, supports Delphi, and can also be embedded in native applications as an important secondary goal. Avoid: JS engine when the recommended defaults or host-tooling shape matters.
Recommended defaults: The recommended out-of-the-box way to use GocciaScript: sandbox-first, modern, and intentionally conservative about legacy JavaScript forms. It describes guidance for new code, not the limit of what the engine or runtime can support when a host opts into compatibility or custom runtime capabilities. Avoid: Language ceiling, hard limit.
Recommended profile: The default-on feature configuration that realises the recommended defaults: the forms and globals GocciaScript exposes without a compatibility or unsafe opt-in. Also written recommended language profile. See Language for the profile and its compatibility paths. Avoid: Language ceiling, hard limit, runtime profile.
Engine: The core language execution layer. It owns language semantics, source type, execution mode dispatch, and core language built-ins. Avoid: Runtime when referring only to core language behavior.
Runtime: The host integration layer attached to an engine. It installs optional globals, file-backed helpers, and runtime extensions. Avoid: Engine, VM.
Runtime extension: An installable host or special-purpose feature added to a runtime, such as console, fetch, data-format globals, testing, benchmarking, or FFI. Avoid: Core language built-in when the feature belongs to the optional runtime surface.
Virtual module: An ECMAScript module whose content is supplied explicitly through host configuration instead of loaded from the ambient filesystem. Virtual modules use the same resolution, linking, evaluation, and caching semantics as other modules. Avoid: Global module, in-memory module when the configuration mechanism is the defining property.
Host module: An ECMAScript module or module provider registered programmatically by an embedding host. A host module may expose host-created values while participating in the ordinary module lifecycle. Avoid: Global module, runtime module when the module is registered directly by an embedder.
Runtime module:
An import-only module installed by a runtime extension, such as a goccia: data-format module.
Avoid: Runtime global, host module.
Module content provider: The host-installed component that retrieves a module's text or bytes once an address has been resolved. Resolution and retrieval are separate concerns: a resolver decides which address to load, a content provider decides how its content is obtained. An engine with no provider installed is not a broken engine — it refuses every retrieval with a script-catchable error carrying a stable code, which is a different condition both from an installed provider that cannot produce a particular module and from a specifier that never resolved, since resolution runs first and fails on its own terms. Avoid: Module resolver, module loader, filesystem when the retrieval mechanism is the defining property.
Runtime profile: A named bundle of runtime extensions used by a CLI host or embedding host. Avoid: Mode, preset.
Runtime surface: The aggregate JavaScript-visible capability set installed by a runtime profile or by individual runtime extensions. Use it when discussing what a host exposes overall; use runtime global, runtime extension, or runtime profile when naming the concrete mechanism. Avoid: Runtime, built-in surface, host surface.
Host environment:
The engine-owned module that supplies JavaScript-observable time, time zone, and randomness. Hosts may inject its clock and RNG adapters; infrastructure timing is not part of the host environment.
Avoid: Runtime surface, global clock, TimingUtils when referring to script-visible values.
Capability audit event: A versioned structured host event emitted when source reaches a capability boundary. It records the capability kind, allow-or-deny decision, subject, reason, and active source location. The decision describes capability policy, not the eventual success of the requested operation. Avoid: Console log, operation result, security policy callback.
Capability audit sink:
The engine-owned host callback that receives capability audit events synchronously. Sink failures propagate and stop execution; CLI hosts provide a thread-safe JSONL sink through --audit-log. A sink is one delivery route for capability audit events, not the only one: sandbox hosts may also receive the same events in the structured run result alongside the filesystem diff.
Avoid: Runtime extension, script-visible logger, best-effort telemetry, effect log.
Resource limit:
The umbrella for engine-enforced execution ceilings: instruction limit, execution timeout, and the memory budget's native-growth gate. A resource limit is enforced by the engine against the running program as a whole, is configured by the host rather than the program, and is not catchable from source. Exceeding one ends execution rather than producing a value source can handle. Only the native-growth gate makes the memory budget a resource limit in this sense; the budget's charged allocation failures are the deliberate exception — they surface as an ordinary catchable RangeError, so they are not part of this umbrella (see Memory budget below). (Capability budget is a separate concept, realised per capability rather than as a program-wide ceiling — see below — so it is not part of this umbrella.)
Avoid: Sandbox permission, capability, quota, script error.
Memory budget:
The per-thread ceiling on allocated bytes, configured through --max-memory. The collector instance is thread-local, so engines that share a thread share one MaxBytes and one BytesAllocated — the ceiling is not isolated per engine. It is enforced two ways, with different failure semantics: allocation sites whose owner can reserve and release the native storage through a reliable hook charge against it and release on destruction, and a refused charge surfaces as an ordinary catchable RangeError; growth points that have a container owner but no such release hook — array element buffers and object property storage — are gated instead — checked before allocating, never charged — and a refused gate raises the uncatchable resource-limit ceiling. Gating bounds any single allocation but not the aggregate of many small ones, so a memory budget bounds peak allocation requests rather than guaranteeing steady-state residency.
Avoid: GC heap size, resident set limit, virtual filesystem quota.
Capability budget: A bound on how often or how much an installed capability may be exercised — at most N invocations, or up to M bytes — after which further use is refused. It narrows a grant that would otherwise be unlimited once installed, and is distinct from whether the capability is installed at all. Avoid: Capability audit event, rate limit, allowlist.
Seed baseline: An explicitly imported snapshot used to initialise a sandbox-visible filesystem. Top-level sandbox seeds copy from host paths or inline seed config entries; nested child sandbox seeds copy from the parent virtual filesystem or inline child entries. A seed baseline is not a live mount and does not make the source path ambiently available to running source. Avoid: Mount, host filesystem access, import baseline.
Metadata diff: An opt-in sandbox diff dimension that reports timestamp changes independently from content and namespace changes. It compares a path's access, modification, change, and birth timestamps against the seed baseline without turning timestamp-only activity into a content modification. Avoid: Default diff, content diff.
Sandbox filesystem error:
A JavaScript Error reported by a sandbox runtime extension when a virtual filesystem operation fails. It carries a stable error code and operation/path context plus a target-appropriate numeric errno. It is shared by synchronous and promise APIs, and by callback APIs when installed.
Avoid: Raw virtual filesystem exception, host filesystem error.
Out-of-process sandbox: An isolation mode in which an isolated sandbox run executes the engine in a separate child process reached over stdio, instead of in the host process. Process separation buys crash containment and turns a wedged native loop into a parent-enforced deadline and hard kill; it is not a syscall jail, which is deferred. The parent materialises the seed baseline into bytes and sends it in the run request, so the child is given no host paths and a well-behaved run needs no host-filesystem access; OS-level confinement that would stop a compromised child from reaching the host filesystem remains deferred. Avoid: Sandbox jail, syscall confinement, worker thread.
Child run: One entry program executed in one out-of-process sandbox child, under the child-per-run model where each isolated run spawns a fresh child that runs exactly one program and exits. A child run reports its own outcome in-band as a failure kind; only the parent, observing the child process, sets the reserved child-process-crash classification. Avoid: Nested sandbox run, pooled child, worker task.
WinterTC compatibility:
The open product direction of aligning selected runtime globals and host behavior with web-interoperable server runtime standards, especially WinterTC's Minimum Common Web API. It is distinct from Node.js host compatibility, CommonJS support, and node: built-ins.
Avoid: WHATWG API compatibility, browser host environment, Node.js host compatibility.
WHATWG API compatibility: The open product direction of implementing selected WHATWG browser and web-platform APIs when they fit GocciaScript's sandboxed runtime and embeddable platform goals. It does not imply a full browser host environment. Avoid: WinterTC compatibility, browser host environment, DOM compatibility.
Built-in: An API supplied by GocciaScript rather than by user source or a host application. Built-ins include both core language built-ins and runtime globals. Avoid: Native function when the implementation mechanism is the point.
Core language built-in: An always-available global object, function, constructor, or constant registered by the engine as part of the language core. Avoid: Runtime global.
Runtime global: An optional global object, function, constructor, or namespace installed by a runtime extension. Avoid: Core language built-in, runtime surface when referring to one global.
FFI callback type: An FFI type descriptor that declares the argument and return types used when native code calls a user-defined function on the callback's owning runtime thread. Avoid: Bare callback type when the signature is not known.
Call-scoped FFI callback: A temporary native callback created when a user-defined function is passed to an FFI callback-typed argument. Its lifetime ends when the enclosing native call returns. Avoid: Persistent callback, retained callback.
Persistent FFI callback: An explicitly created, closable callback handle whose native entry point remains valid across native calls until the handle is closed. Avoid: Call-scoped callback, raw callback pointer.
FFI library guard: A shared lifetime record retained by an open native library and every bound function or symbol derived from it. It separates logical closure from physical library unloading. Avoid: Raw library handle, owning bound function.
Logical FFI close: The immediate invalidation of a native library and its derived values; physical unloading occurs later when no FFI library guards remain. Avoid: Immediate unload, delayed close.
FFI aggregate type: A compositional FFI type descriptor for a structure, union, or fixed-length array. Aggregate types may nest and may appear in native by-value argument and return positions. Avoid: Buffer layout when the value participates in native ABI marshalling.
Shim: A GocciaScript-provided legacy ECMAScript surface layered over a newer native capability so conformance can include old names without making them the recommended path for new code. Avoid: Polyfill, compatibility flag.
Execution mode: The selected way to execute source: interpreter mode or bytecode mode. Avoid: Runtime, runtime profile.
Deterministic execution: An engine profile in which JavaScript-observable time is frozen at the Unix epoch, the time zone is UTC, and randomness comes from a fixed portable seed. Infrastructure clocks remain live, and child realms receive distinct reproducible random streams. Avoid: Deterministic profiling, frozen timeout clock, seeded sandbox filesystem.
Executor: The implementation object behind an execution mode. GocciaScript has an interpreter executor and a bytecode executor. Avoid: Execution backend, runtime.
Source pipeline: The shared source-processing pipeline that turns source text into an AST before execution. It owns parser policy and exposes purpose-specific parse entry points for full source, module source, dynamic Function parsing, and expression fragments. Avoid: Source frontend, CLI host when discussing lexer/parser/AST behavior.
Parser policy: The source-pipeline settings that determine how source text is parsed, including source type and the compatibility flag set. Avoid: Separate parser booleans when discussing the policy as a whole.
CLI host: A command-line program that hosts the engine or runtime for a specific workflow. Avoid: CLI frontend, source pipeline.
CLI option:
A named command-line control such as --mode=bytecode, --output=json, or --print. Use it as the umbrella term for named CLI controls, whether they take a value or not.
Avoid: CLI flag when the option takes a value.
CLI flag:
A boolean CLI option that toggles behavior by its presence, such as --print, --compat-asi, or --unsafe-ffi.
Avoid: CLI flag for value-taking controls.
Positional argument:
A non-option CLI input whose meaning comes from position, such as an entry file, test path, benchmark path, or - stdin marker.
Avoid: CLI option, CLI flag.
Entry file: The initial script or module file path that starts a single program run. It anchors entry-specific behavior such as script-vs-module source type, root config discovery, and default relative module resolution. Avoid: Input file when only the initial program path matters.
Input file: Any file processed by a CLI host, especially batch-capable tools such as the Test Runner, Benchmark Runner, Bundler, or multifile processing. Avoid: Entry file when referring to a batch member or per-file result.
Config key:
A field name in a GocciaScript config file, such as "mode", "strict-types", or "allowed-hosts".
Avoid: Config option when referring to the field name.
Config value:
The value assigned to a config key and the selected setting it carries, such as "bytecode", true, or ["api.example.com"].
Avoid: Config option when referring to the serialized value.
Tree-walk execution: Execution by walking the AST through the interpreter and evaluator. Avoid: Bytecode execution.
Bytecode execution: Execution by compiling the AST to Goccia bytecode and running it on the Goccia VM. Avoid: VM mode.
Goccia bytecode:
The GocciaScript-owned instruction format used by bytecode execution and stored in .gbc artifacts.
Avoid: Generic VM bytecode.
Goccia VM: The virtual machine that executes Goccia bytecode for GocciaScript. Avoid: Generic VM layer.
Inline cache: A per-site cache on a function template that lets the Goccia VM re-read a previously resolved global binding or property by entry index instead of by name. Global-read entries validate scope identity and binding-map version; property-read entries validate interned shapes. A site whose receivers keep changing becomes megamorphic and reads through the uncached fast path instead. Avoid: Hidden class, polymorphic inline cache — GocciaScript property caches are monomorphic per site.
Shape: The interned, per-realm identity of an object's own-property layout: the sequence of property keys added to its property map. Two objects with the same shape store the same key at the same entry index. A shape records keys only — not the prototype, not attribute flags, not values. If a property map is asked to materialize its shape from a non-owner realm, it leaves shape tracking instead of interning the owner's layout into the foreign realm's table. Avoid: Hidden class, map (overloaded with the property map and the Map built-in).
Dictionary mode: The state a property map enters when its layout stops being shape-tracked (after a property delete or clear, or after a non-owner realm tries to ensure its shape). Dictionary-mode objects stay fully functional but are invisible to shape-validated inline caches. Avoid: Slow mode, deoptimized object.
Source text: The UTF-16 textual contents of GocciaScript code, independent of whether it came from a file, stdin, or an embedding host. Source text is ECMAScript text, not encoded file bytes. Avoid: Source file when referring to in-memory contents.
Source file bytes: The encoded bytes of a source file before decoding into source text. Avoid: Source text, UTF-8 string.
ECMAScript text: Text represented as UTF-16 code units according to ECMAScript string semantics, including the ability to preserve lone surrogate code units. Source text, identifiers, property keys, and runtime string values are ECMAScript text. Avoid: UTF-8 string, byte string.
Canonical text representation: The single in-memory form of ECMAScript text, preserving every UTF-16 code unit including lone surrogates. Avoid: Internal UTF-8 representation, byte-backed string, text mode.
ECMAScript semantic boundary: A text operation whose behavior is defined by ECMA-262 or ECMA-402. Its indexing, lone-surrogate handling, normalization, casing, encoding, parsing, and error behavior follow the applicable specification; host encoding policy applies only where the specification delegates the choice to the host. Avoid: Generic Unicode behavior, platform string behavior, host text policy.
Encoded text bytes: A byte sequence in a named external encoding, such as UTF-8, before decoding into ECMAScript text or after encoding it for output. Encoded text bytes exist only at host, file, network, serialization, or binary-data boundaries and are not a kind of in-memory string. Avoid: String, UTF-8 string, source text, ECMAScript text.
Strict UTF-8 input: Encoded text bytes that must decode as well-formed UTF-8 before entering the source pipeline or a structured-text parser. Invalid input is rejected rather than repaired. Avoid: Best-effort text, replacement decoding.
Replacement decoding:
UTF-8 decoding that substitutes U+FFFD for malformed byte sequences because the governing API contract explicitly requires recovery, as with a non-fatal TextDecoder.
Avoid: Default file decoding, strict UTF-8 input.
Text API: A host-facing or internal API whose text parameters and results are ECMAScript text rather than encoded bytes. Avoid: UTF8String overload, encoded text API.
Encoded-text API: An API whose parameters or results are encoded text bytes and whose contract identifies the encoding operation. Avoid: String overload, implicit encoding adapter.
FFI UTF-8 string:
A NUL-terminated native char* whose payload is well-formed UTF-8 and contains no embedded NUL. It is distinct from ECMAScript text and from an arbitrary byte pointer.
Avoid: cstring, ANSI string, native string.
Text buffer: A mutable builder whose elements and length are UTF-16 code units. Avoid: Byte buffer, AnsiString buffer.
Byte buffer: A mutable builder for encoded or binary data whose elements and length are bytes. Avoid: Text buffer, byte string.
Delphi parity: The supported-compiler state in which every shipped executable compiles and runs across the declared Delphi target matrix and the complete applicable local test inventory passes with the expected semantics. Avoid: Delphi compatibility, representative Delphi smoke test, core-engine-only support.
Delphi project group: A repository-owned set of IDE project definitions that builds the shipped executable inventory under Delphi. Avoid: Opening individual DPR files as the supported build, compliance harness group.
Compliance runner: An internal native application that coordinates execution of a prepared, pinned external conformance suite, verifies the suite revision, isolates individual cases, and emits human-readable and machine-readable results. A compliance runner is not a shipped runtime tool or a single-input decoder harness. Avoid: Test runner, compliance harness, suite downloader.
Host path: A Unicode path interpreted by the host operating system or embedding filesystem rather than by ECMAScript. Avoid: Encoded text bytes, source text, UTF-8 path.
Source span: A zero-based half-open range of UTF-16 code-unit offsets within source text. Token and AST locations use source spans as their canonical coordinates; line and column values are derived at reporting boundaries. Source maps expose zero-based UTF-16 columns as required by ECMA-426, while user-facing errors and stack traces expose one-based line and column values. Avoid: Byte range, character range, independently tracked line and column.
Source character:
A Unicode code point consumed by the ECMAScript lexical grammar from source text. A valid UTF-16 surrogate pair contributes one source character while an unpaired surrogate contributes one source character of width one code unit; source spans continue to count the underlying code units.
Avoid: Pascal Char, byte, grapheme, source span.
RegExp index:
A zero-based UTF-16 code-unit offset used by RegExp capture slots, match indices, lastIndex, replacement operations, and d-flag index pairs. Unicode-aware matching may consume a valid surrogate pair as one code point, but externally observable RegExp indices always remain code-unit offsets.
Avoid: Byte index, code-point index, character index.
String index: A zero-based UTF-16 code-unit offset into an ECMAScript String. Ordinary indexed String operations use string indices; only operations explicitly defined in terms of Unicode code points combine valid surrogate pairs. Avoid: Byte index, grapheme index, implicit Pascal string index.
Template token value: The semantic payload of a template token: exact raw text, cooked text, and whether the cooked value is valid. Invalid escapes in tagged templates retain their raw value while making the cooked value unavailable. Avoid: Packed template string, separator character, decoded template text.
Embedded resource artifact: A committed binary resource container generated by a pinned update workflow and consumed unchanged by supported native compilers. Avoid: Delphi-generated resource copy, string resource buffer, runtime-generated resource.
Numeric text conversion:
The conversion between exact decimal text and ECMAScript binary64 Number values, including ties-to-even parsing and shortest-roundtrip formatting.
Avoid: FloatToStr, StrToFloat, presentation formatting, locale formatting.
Native number arithmetic: Ordinary binary64 arithmetic over ECMAScript Number values, including NaN, infinities, signed zero, rounding, overflow, and underflow. Avoid: Shadow arithmetic backend, custom IEEE-754 engine, manual special-value arithmetic.
ECMAScript numeric guard: An explicit special-case step required by an ECMA-262 numerical algorithm before or after native number arithmetic. It applies consistently across compilers even when a particular compiler's routine happens to produce the same result. Avoid: Compiler workaround, NaN subsystem, defensive arithmetic branch.
Numeric compatibility adapter: A narrowly scoped, probe-backed bridge to platform numerical functionality used when the supported Pascal RTL routines cannot implement one ECMAScript operation across the target matrix. It supplies that operation without replacing native number arithmetic. Avoid: Arithmetic backend, speculative workaround, compiler-specific number mode.
Number remainder:
The exact ECMA-262 Number::remainder operation over two binary64 Number values, including its NaN, infinity, signed-zero, normal, and subnormal results. It is distinct from BigInt remainder and from similarly named host-language or RTL operations.
Avoid: Modulo, Math.FMod, floating-point mod, BigInt remainder.
Floating-point execution scope: A bounded execution context that establishes ECMAScript-compatible floating-point rounding and exception behavior while preserving the host's inherited state. Avoid: Custom Win32 arithmetic backend, permanent process FPU mutation, blanket forced-store wrapper.
Preprocessor: A source-to-source transformation applied before the source pipeline lexes and parses source text. JSX is the current preprocessor. Avoid: JSX flag when referring to the general mechanism.
Source type: The setting that chooses whether an entry file is evaluated as script source or module source. It may be explicit or inferred from the entry file name. Avoid: Mode, module mode, script mode.
Script source: Source evaluated with script entry semantics. Avoid: Module source.
Module source:
Source evaluated with module entry semantics, including module this, imports, exports, and import metadata.
Avoid: Script source.
Script Loader:
The CLI host that executes source files, stdin, or .gbc artifacts.
Avoid: Script executor.
Bare Script Loader: The CLI host that executes through the core engine without attaching the runtime surface. Avoid: Loader profile.
Sandbox Runner:
The CLI host (GocciaSandboxRunner) that executes an entry file inside an isolated sandbox virtual filesystem populated from a seed baseline, and reports a structured run result. See Architecture and Build System.
Avoid: Script Loader, sandbox mode.
Test Runner:
The CLI host (GocciaTestRunner) that discovers and runs GocciaScript test files against the built-in Vitest-compatible testing API and reports per-file and aggregate results. See Testing.
Avoid: Compliance runner, test harness.
Benchmark Runner:
The CLI host (GocciaBenchmarkRunner) that runs benchmark files and reports timing and score measurements for one or more suites. See Benchmarks.
Avoid: Performance Barometer, profiler.
REPL:
The interactive CLI host (GocciaREPL) that evaluates entered source in one persistent realm across inputs.
Avoid: Script Loader, shell.
Differential suite: A shared test suite executed both on GocciaScript and on an external runtime in continuous integration, so a behavioral disagreement in either direction fails the build. See Differential Testing. Avoid: Conformance suite, compatibility test.
Semantics oracle: The external runtime whose observed behavior decides the expected result for a differential suite — Vitest for the testing-API suites, Bun for the language suites. An advisory runtime informs a suite without deciding it. Avoid: Reference engine, baseline runtime.
Drop-in replacement: The stated direction of the testing API: that existing Vitest suites run unchanged on the Test Runner. It is the direction, not a finished claim — the current divergences are recorded in Test Framework API. Avoid: Vitest compatible as an unqualified claim, full parity.
Test262 host capability:
A JavaScript-visible hook exposed on the Goccia namespace only when a CLI host opts into the test262 conformance contract, such as GocciaScriptLoaderBare --test262-host. It is not a core language built-in and not part of the normal runtime surface.
Avoid: Runtime global, compatibility flag.
Compatibility dashboard:
The /compatibility page on the project website, rendered from the generated test262 reports. It is the canonical home of conformance figures; documentation and website copy link to it instead of quoting a pass rate.
Avoid: Conformance table, hand-typed pass rate, Performance Barometer.
Wrapper infrastructure failure: A test262 result class for a case whose run failed outside the conformance contract — a signal-killed engine process, a Pascal-side error, or a negative-runtime path that emitted no marker at all. It is distinct from a conformance failure and from a timeout, and is gated to zero in continuous integration. See test262. Avoid: Conformance fail, flaky test, harness error.
Performance Barometer: The public, directional view of GocciaScript performance against selected reference engines using retained, versioned benchmark reports. It is a north-star aid, not a product ranking. Avoid: Leaderboard, competitor comparison.
Reference engine: An independently developed JavaScript engine or runtime measured beside GocciaScript to provide external scale and trend context. A reference engine is not assumed to share GocciaScript's goals or constraints. Avoid: Competitor, baseline engine.
Reference ratio:
A dimensionless comparison normalized so 1.00× means aligned performance and a value above 1.00× means GocciaScript was proportionally slower. For elapsed-time suites it is Goccia time divided by reference time; for score suites it is reference score divided by Goccia score.
Avoid: Speedup, ranking score.
North-star trend: The retained direction of compatible reference-ratio measurements over time. A trend line breaks when the corpus, subset, driver, or reference-engine version changes rather than implying continuity across different measurement contracts. Avoid: Release gate, competitive ranking.
Profile report: A retained performance-review artifact published by main-branch test262 and benchmark runs. It pairs an aggregate entry point — provenance, rollups, ranked hotspots — with detailed per-area profiles that explain a ranked row. A profile report is review material, not conformance evidence and not a gate. See Profiling and test262. Avoid: Conformance report, benchmark result, compatibility dashboard input.
Bundler:
The CLI host that compiles source to .gbc artifacts without executing the program.
Avoid: Compiler when referring to the user-facing tool.
Value: The runtime representation of JavaScript data in GocciaScript. Avoid: Object when primitives are included.
Literal: Source syntax that directly denotes a value. Avoid: Runtime value when discussing stored or computed data.
Scope:
The lexical context used to resolve bindings and contextual values such as this, super, and new.target.
Avoid: Object, namespace.
Binding: A named association in a scope. Most bindings hold a value directly; an import binding indirectly names an exported binding in another module. Avoid: Raw variable.
Import binding: An immutable indirect binding created by a module import that refers to an exported binding in another module. Each read observes the target binding's current value and initialization state. Avoid: Imported value, import snapshot.
Define: Create a new binding in the current scope. Avoid: Assign.
Assign: Change the value of an existing binding. Avoid: Define.
Realm: The ECMAScript execution domain for code: its own intrinsics, global object, global environment, loaded code state, and host-associated resources. Avoid: Runtime, process-wide singleton, prototype cache.
Native function: A GocciaScript-callable function whose body is implemented in Pascal. It may come from the engine, a runtime extension, or an embedding host. Avoid: Built-in when the function is host-provided rather than language-provided.
User-defined function: A function whose body is written in GocciaScript source. This includes arrow functions and opt-in compatibility functions. Avoid: User function, if arrow-only behavior is not intended.
Arrow function:
A source-level => function with lexical this.
Avoid: User-defined function when lexical this is the important distinction.
Ordinary function:
A non-arrow source-defined function with call-site this semantics.
Avoid: Arrow function, method.
Method:
A class or object shorthand function that receives its call-site receiver as this.
Avoid: Arrow method.
Compatibility flag:
An explicit boolean CLI flag or config value, using canonical compat-* spelling, that enables an ECMAScript behavior disabled by the recommended profile.
Avoid: Feature flag when the option exists for compatibility semantics.
Compatibility flag set:
The aggregate source-pipeline setting that carries enabled compatibility flags together, such as compat-asi, compat-var, compat-function, or compat-non-strict-mode.
Avoid: Separate compatibility booleans when a caller is passing the whole parser compatibility policy.
Runtime: Use Runtime for the host integration layer. Use runtime value, runtime behavior, or runtime error when speaking generically about behavior during execution.
Executor vs mode: Use execution mode for the user-visible selection. Use executor for the implementation object that makes the mode work.
Option vs flag:
Use CLI option as the umbrella term. Use CLI flag only for boolean options; call value-taking controls such as --mode=bytecode, --output=json, and --timeout=1000 options.
Config key vs config value: Use config key for the field name in a config file. Use config value for the assigned value and the selected setting it configures.
Entry file vs input file: Use entry file for the initial script or module file path that starts a single program run. Use input file for files processed by batch-style tools or per-file result envelopes.
Source type vs execution mode: Use source type for script-vs-module entry semantics. Use execution mode for interpreter-vs-bytecode execution.
Native vs built-in: Use native function for Pascal-backed callables. Use built-in for APIs supplied by GocciaScript. Use core language built-in or runtime global when availability matters.
Runtime surface vs runtime global: Use runtime surface for the aggregate host-exposed capability set. Use runtime global for one JS-visible global installed by a runtime extension.
Function vocabulary: Use user-defined function for source-defined functions in general. Use arrow function, ordinary function, or method only when that semantic distinction matters.
Script Loader:
Use Script Loader for GocciaScriptLoader. Avoid script executor except when describing the generic act of executing source.
Frontend/backend terminology: Avoid frontend/backend terminology in GocciaScript architecture. Use source pipeline for lexer/parser/AST work and CLI host for command-line programs.
Dev: Should fetch be registered by the engine?
Domain expert: No. fetch is a runtime global installed by a runtime extension, usually through the loader runtime profile.
Dev: Is this an executor bug? Domain expert: It depends. If interpreter mode and bytecode mode disagree, it is probably an executor issue. If both execution modes agree but the language behavior is wrong, it is an engine semantics issue.
Dev: Is --mode=bytecode a flag?
Domain expert: No. It is a CLI option because it takes a value. --print is a CLI flag because it is boolean.
Dev: Is "mode" a config option?
Domain expert: Call "mode" the config key. Call "bytecode" the config value.
Dev: Should this JSON envelope say entry files? Domain expert: If it reports every file a batch run processed, say input files. Use entry file only for the initial program path.
Dev: Is --source-type=module module mode?
Domain expert: No. It sets the source type to module source. Execution mode is interpreter or bytecode.
Dev: The callback is a built-in function because it is written in Pascal, right? Domain expert: It is a native function because it is Pascal-backed. It is only a built-in if the engine or runtime surface provides it as part of GocciaScript.
Dev: Can this test say "user function"? Domain expert: Prefer "user-defined function" unless the test specifically means an arrow function, ordinary function, or method.