numbl 0.4.19 → 0.4.22

package/dist-lib/numbl-core/executors/jit/cJitCallExecutor.d.ts

@@ -1,35 +0,0 @@
-/**
- * cjit-call — C-backed JIT executor for user-function calls.
- *
- * Mirrors `callExecutor.ts` (the JS-emit sibling) but routes the
- * specialization's emitted code through `compileSpecC` →
- * `cc -shared -fPIC -O3` → `dlopen` via koffi instead of
- * `new Function(source)`. The dispatch, gating, and caching
- * conventions are otherwise identical, so a sibling executor can
- * register alongside the JS path at the same opt level without any
- * arbitration in the dispatcher beyond cost-based selection.
- *
- * Declines when:
- *   - `nativeBridge` / `koffi` are not available (browser).
- *   - Any param or output type fails the C-FFI feasibility check
- *     (`compilerTypeToCDecl` returns null).
- *   - mtoc2 throws `UnsupportedConstruct` / `JitTypeError` at lowering.
- */
-import type { Executor } from "../types.js";
-import { type JitType } from "../../jitTypes.js";
-import type { FunctionDef } from "../../interpreter/types.js";
-import { type Type as CompilerType, type SpecCSignature } from "../../jit/index.js";
-import { type CompiledC } from "./compileC.js";
-interface CJitCallData {
-    readonly fn: FunctionDef;
-    readonly nargout: number;
-    readonly argTypes: readonly JitType[];
-    readonly compilerArgTypes: readonly CompilerType[];
-    readonly args: readonly unknown[];
-}
-interface CompiledArtifact {
-    readonly compiled: CompiledC;
-    readonly signature: SpecCSignature;
-}
-export declare const cJitCallExecutor: Executor<CJitCallData, CompiledArtifact | null>;
-export {};

package/dist-lib/numbl-core/executors/jit/cJitLoopExecutor.d.ts

@@ -1,31 +0,0 @@
-/**
- * cjit-loop — C-backed JIT executor for outermost For/While
- * loops. Mirrors `loopExecutor.ts` (JS-emit sibling) but routes
- * through `compileSpecC` → `cc -shared` → `koffi`. See
- * `cJitCallExecutor.ts` for the marshaling protocol; this file just
- * adapts the loop-shape `data` to the same C-side pipeline.
- */
-import type { Executor } from "../types.js";
-import { type JitType } from "../../jitTypes.js";
-import type { Stmt } from "../../parser/index.js";
-import type { ConstHandle } from "../classification.js";
-import { type Type as CompilerType, type SpecCSignature } from "../../jit/index.js";
-import { type CompiledC } from "./compileC.js";
-interface CJitLoopData {
-    readonly loopStmt: Stmt & {
-        type: "For" | "While";
-    };
-    readonly inputs: readonly string[];
-    readonly outputs: readonly string[];
-    readonly inputTypes: readonly JitType[];
-    readonly compilerInputTypes: readonly CompilerType[];
-    readonly constHandles: readonly ConstHandle[];
-    readonly currentFile: string;
-    readonly cacheKey: string;
-}
-interface CompiledArtifact {
-    readonly compiled: CompiledC;
-    readonly signature: SpecCSignature;
-}
-export declare const cJitLoopExecutor: Executor<CJitLoopData, CompiledArtifact | null>;
-export {};

package/dist-lib/numbl-core/executors/jit/cJitTopLevelExecutor.d.ts

@@ -1,29 +0,0 @@
-/**
- * cjit-top-level — C-backed JIT executor for whole-script bodies.
- *
- * Mirrors `topLevelExecutor.ts` (JS-emit sibling) but routes through
- * `compileSpecC` → `cc -shared` → `koffi`. See `cJitCallExecutor.ts`
- * for the marshaling protocol. Same `isAllSuppressed` gate as the JS
- * sibling so `displayAssign`/`displayResult` semantics stay on the
- * interpreter path.
- */
-import type { Executor } from "../types.js";
-import { type JitType } from "../../jitTypes.js";
-import type { Stmt } from "../../parser/index.js";
-import { type Type as CompilerType, type SpecCSignature } from "../../jit/index.js";
-import { type CompiledC } from "./compileC.js";
-interface CJitTopLevelData {
-    readonly stmts: readonly Stmt[];
-    readonly inputs: readonly string[];
-    readonly outputs: readonly string[];
-    readonly inputTypes: readonly JitType[];
-    readonly compilerInputTypes: readonly CompilerType[];
-    readonly currentFile: string;
-    readonly cacheKey: string;
-}
-interface CompiledArtifact {
-    readonly compiled: CompiledC;
-    readonly signature: SpecCSignature;
-}
-export declare const cJitTopLevelExecutor: Executor<CJitTopLevelData, CompiledArtifact | null>;
-export {};

package/dist-lib/numbl-core/helpers/dummy.d.ts

@@ -1,5 +0,0 @@
-/**
- * Dummy no-op built-in function names.
- * Used as placeholders for unsupported functionality.
- */
-export declare function getDummyBuiltinNames(): string[];

package/dist-lib/numbl-core/jit/runtime/context.d.ts

@@ -1,23 +0,0 @@
-/**
- * Host bag passed to `Builtin.call` for the interpreter backend.
- *
- * Mirrors nexl's `RuntimeContext`. Side-effecty builtins (`disp`,
- * `fprintf`, `error`, plot dispatch, …) consult `helpers.write` to
- * emit text. Pure builtins ignore the bag.
- *
- * `write` is the JS analogue of C's `printf`. The CLI provides one
- * backed by `process.stdout.write`; the browser provides one that
- * pushes lines to the console panel; future test runners provide
- * one that captures into a buffer for byte-for-byte comparison.
- *
- * As the interpreter grows, additional hooks (`time`, `plot`,
- * `error`, …) will join this bag. Adding a hook here is the
- * single source of truth — every host supplies it.
- */
-export interface RuntimeHelpers {
-    /** Append text to stdout. No implicit newline. */
-    write(s: string): void;
-}
-export interface RuntimeContext {
-    helpers: RuntimeHelpers;
-}

package/dist-lib/numbl-core/jit/runtime/inferType.d.ts

@@ -1,10 +0,0 @@
-/**
- * Map a runtime value back into a Type. Used by the interpreter to
- * feed `argTypes` into a builtin's `transfer` (for validation) and
- * `call` (for type-dispatched implementations) — so that the three
- * hooks (`emitC`, `emitJs`, `call`) all branch on the same `argTypes`
- * shape rather than reinventing dispatch per-backend.
- */
-import { type Type } from "../lowering/types.js";
-import { type RuntimeValue } from "./value.js";
-export declare function inferTypeFromValue(v: RuntimeValue): Type;

package/dist-lib/numbl-core/jit/runtime/value.d.ts

@@ -1,101 +0,0 @@
-/**
- * Runtime value carrier for the interpreter backend. Mirrors nexl's
- * `RuntimeValue` design: a discriminated-via-typeof union for the
- * common cases plus tagged-object wrappers for the kinds JS can't
- * distinguish natively.
- *
- * MVP scope (Phase 3): real-double scalars, booleans (logical),
- * strings (double-quoted), chars (single-quoted), real-double tensors.
- * Complex / structs / classes / handles / void / cells follow as the
- * type lattice and interpreter coverage expand.
- *
- * Builtin `call` implementations narrow via `typeof` / `isTensor` /
- * `isChar` and dispatch through the same `argTypes` shape that
- * `emitC` / `emitJs` consume — keeping the three backends parallel.
- */
-export type RuntimeValue = number | boolean | string | RuntimeTensor | RuntimeChar | RuntimeComplex | RuntimeStruct | RuntimeHandle;
-/** Function handle. Named handles (`@foo`) keep the source name and
- *  dispatch via the interpreter's normal call-site resolution at the
- *  call point. Anonymous handles (`@(p1, ...) body`) capture every
- *  visible binding by value at the @-site and run `body` in a fresh
- *  env when invoked. */
-export type RuntimeHandle = {
-    readonly mtoc2Handle: true;
-    readonly kind: "named";
-    readonly name: string;
-} | {
-    readonly mtoc2Handle: true;
-    readonly kind: "anon";
-    readonly params: ReadonlyArray<string>;
-    readonly body: unknown;
-    readonly captures: Readonly<Record<string, RuntimeValue>>;
-};
-/** Narrow a RuntimeValue to a function handle. */
-export declare function isHandleValue(v: RuntimeValue): v is RuntimeHandle;
-/** Struct/object — plain JS object whose keys are field names. The
- *  c-aot path emits a typedef'd C struct; the JS path just uses a
- *  bare object. Recurses through field values that may themselves be
- *  any RuntimeValue (including nested structs). */
-export type RuntimeStruct = {
-    readonly [field: string]: RuntimeValue;
-};
-/** Real or complex double tensor. `data` is the real lane,
- *  column-major to match numbl's `RuntimeTensor.data`. `imag` is the
- *  imaginary lane (same length and orientation as `data`); absent for
- *  real-only tensors. Mirrors the C representation's split-buffer
- *  layout — codegen / interpreter dispatch on `imag !== undefined`
- *  the way the C side dispatches on `imag != NULL`. The shape array
- *  is owned by the value; do not mutate.
- *
- *  `isLogical` flags this tensor as the result of a logical operation
- *  (`~`, `<`, `==`, `&&`, …) so downstream index-slot resolution can
- *  treat it as a mask instead of an IndexVec — same role as numbl's
- *  `_isLogical` on its RuntimeTensor. The flag is one-way (once set,
- *  stays set across copies via the helper) and absent on numeric
- *  tensors; helper sites that don't care leave it undefined. */
-export interface RuntimeTensor {
-    readonly mtoc2Tag: "tensor";
-    readonly shape: number[];
-    readonly data: Float64Array;
-    readonly imag?: Float64Array;
-    readonly isLogical?: boolean;
-}
-/** Single-quoted char-array (`'foo'`). Distinct from `"foo"` strings
- *  because numbl treats them differently: `length('foo') === 3` but
- *  `length("foo") === 1`. */
-export interface RuntimeChar {
-    readonly mtoc2Tag: "char";
-    readonly value: string;
-}
-/** Scalar complex value — JS-side analogue of the `mtoc2_complex_t`
- *  struct in `cscalar.h`. The cscalar runtime helpers
- *  (`mtoc2_cmake`, `mtoc2_creal`, etc.) consume and produce this
- *  shape. We DON'T tag it the way tensor / char are tagged because
- *  emitJs literals (`{re: 0, im: 1}`) and runtime calls produce the
- *  bare object form — adding a tag would force every helper to
- *  re-wrap. Use `isComplexValue` for narrowing. */
-export interface RuntimeComplex {
-    readonly re: number;
-    readonly im: number;
-}
-/** Narrow a RuntimeValue to a complex scalar. Matches the cscalar
- *  helpers' `{re, im}` shape. */
-export declare function isComplexValue(v: RuntimeValue): v is RuntimeComplex;
-export declare function makeTensor(shape: number[], data: Float64Array): RuntimeTensor;
-/** Complex tensor with both lanes. `data` is the real lane, `imag`
- *  the imaginary lane; both must have the same length and match the
- *  product of `shape`. */
-export declare function makeComplexTensor(shape: number[], data: Float64Array, imag: Float64Array): RuntimeTensor;
-/** True iff this tensor carries an imaginary lane. */
-export declare function isComplexTensor(v: RuntimeTensor): boolean;
-export declare function makeChar(value: string): RuntimeChar;
-export declare function isTensor(v: RuntimeValue): v is RuntimeTensor;
-export declare function isChar(v: RuntimeValue): v is RuntimeChar;
-/** Materialize a scalar value as a plain JS number. Used by builtins
- *  that need to treat scalar tensors and scalar numbers uniformly. */
-export declare function toScalarNumber(v: RuntimeValue): number;
-/** MATLAB-style truthiness — for `if` / `while` / `&&` / `||`.
- *  Scalar non-zero, all-elements-non-zero for tensors, nonempty
- *  text. The interpreter uses this; codegen relies on the matching
- *  C-side `__nonzero` helpers. */
-export declare function isTruthy(v: RuntimeValue): boolean;

package/dist-lib/numbl-core/jit/workspace/driverPrologue.d.ts

@@ -1,59 +0,0 @@
-/**
- * Driver-script prologue extractor.
- *
- * mtoc2 accepts `addpath(<literal>, ...)` only as a leading sequence
- * of top-level statements in the driver script. Each call is parsed
- * into a list of directory arguments (literal strings only) plus an
- * optional trailing `-begin` / `-end` flag.
- *
- * Two call sites:
- *  - The CLI invokes the extractor before scanning the filesystem so
- *    it knows which directories to fold into the workspace search
- *    path.
- *  - `translateProject` / the interpreter run path invoke it purely
- *    to drop the prologue statements from the driver AST before
- *    lowering / execution begins. The dirs are ignored there.
- *
- * The two calls are idempotent: same input AST → same dirs and
- * remaining body, so it doesn't matter that they parse twice.
- *
- * Any `addpath` left in the AST (anywhere outside the leading prefix)
- * still hits the `addpath` builtin's `transfer`, which errors with a
- * span-attributed message. `rmpath` / `savepath` are always rejected
- * by their own `transfer` hooks; the extractor never accepts them.
- *
- * Function-file auto-invoke: a driver whose body (after the prologue)
- * contains only function/classdef definitions and no top-level
- * statements is a "function file" — running it means calling its
- * first function with zero arguments. The extractor appends a
- * synthesized 0-arg call so every execution path (interpreter,
- * js-aot, c-aot) treats it the same way. Mirrors numbl's
- * `Interpreter.run` (interpreter.ts).
- */
-import type { AbstractSyntaxTree, Stmt, Span } from "../parser/index.js";
-export interface AddPathDir {
-    /** Directory string as the user wrote it. Relative paths are NOT
-     *  resolved here; callers resolve against `process.cwd()`. */
-    dir: string;
-    /** Whether the directory inserts at the front of the addpath block
-     *  (default / `-begin`) or after the CLI `--path` dirs at the end
-     *  (`-end`). */
-    position: "begin" | "end";
-    /** Span of the originating `addpath(...)` call. */
-    span: Span;
-}
-export interface DriverPrologueOpts {
-    /** Set to `true` when a filesystem is available to resolve dirs
-     *  against (CLI). When `false` or omitted (web IDE, in-memory
-     *  translate, vitest), any leading `addpath` call is itself an
-     *  `UnsupportedConstruct`. */
-    allowAddpath?: boolean;
-}
-export interface DriverPrologueResult {
-    addpaths: AddPathDir[];
-    /** Top-level statements after the prologue. Suitable for direct
-     *  use with `Lowerer.lowerProgram` (via a shallow AST copy with
-     *  this `body`) or `Interpreter.runProgram`. */
-    remainingBody: Stmt[];
-}
-export declare function extractDriverPrologue(ast: AbstractSyntaxTree, opts?: DriverPrologueOpts): DriverPrologueResult;

package/dist-lib/numbl-core/jit/workspace/mtoc2UserFunctionLoader.d.ts

@@ -1,62 +0,0 @@
-/**
- * Loader for `.mtoc2.js` user functions.
- *
- * A `.mtoc2.js` file is plain JavaScript with no mtoc2 dependency.
- * The loader evaluates it as a CommonJS-style module (`exports` and
- * `module.exports` are the only injected names) and reads four
- * exports to assemble a workspace-scoped `Builtin`:
- *
- *   exports.name      — string, must match the file's basename.
- *   exports.transfer  — (argTypes, nargout) -> Type[]. Raw mtoc2 Type
- *                       objects in, raw Type objects out. Throws
- *                       `Error` on bad input.
- *   exports.emit      — ({argsC, prefix, ...}) -> string. C expression
- *                       for the call. Use `prefix` to name any private
- *                       C helpers (kept collision-free across files).
- *   exports.cBody     — ({prefix}) -> string. C source (helper
- *                       function definitions) injected once per
- *                       translation unit. Use the same `prefix` as
- *                       `emit`.
- *   exports.cHeaders? — string[] of additional `#include` lines to
- *                       activate (optional).
- *
- * Prefix shape: `mtoc2_user_<safe_funcname>__<8hex>__` where the hex
- * is the FNV-1a hash of the workspace-relative file path. Including
- * the path in the hash makes the prefix unique across all `.mtoc2.js`
- * files in the workspace, even if two files happen to define
- * functions with overlapping internal names.
- */
-import type { Builtin } from "../builtins/registry.js";
-/** Resolved sibling file: the relative path (used by the build to
- *  pick a unique on-disk name) plus the file's text. */
-export interface ResolvedCSource {
-    /** Path as written by the user in `exports.cSources` (e.g.
-     *  `"impl.c"` or `"sub/helpers.h"`). */
-    relPath: string;
-    /** File text the build will write to disk. */
-    source: string;
-}
-/** Loader output: the assembled `Builtin` plus the user-supplied C
- *  sibling files the framework needs to thread through to the build
- *  pipeline. */
-export interface LoadedUserFunction {
-    builtin: Builtin;
-    cSources: ResolvedCSource[];
-}
-/** Evaluate a `.mtoc2.js` file and return its assembled `Builtin`
- *  plus the user-supplied sibling C files (`cSources`).
- *
- *  - `fileName` — the .mtoc2.js's full path (used for diagnostics and
- *    to resolve sibling paths).
- *  - `expectedName` — what numbl's workspace registered the file
- *    under (derived from the file's basename / package path); we
- *    validate the user's `exports.name` matches so a typo / rename
- *    surfaces here rather than at the first call site.
- *  - `relPath` — workspace-relative path used for the prefix hash.
- *  - `readSibling(p)` — given a path-key relative to the .mtoc2.js's
- *    directory, return the sibling file's source text. Used to pull
- *    `cSources` entries out of the workspace's file map (which is
- *    the same regardless of CLI vs web IDE). Returns `undefined` if
- *    the file is not in the workspace; the loader throws a clear
- *    error pointing at the missing path. */
-export declare function loadMtoc2UserFunction(fileName: string, source: string, expectedName: string, relPath: string, readSibling: (siblingRelPath: string) => string | undefined): LoadedUserFunction;

package/dist-lib/numbl-core/native/bridge-resolve.d.ts

@@ -1,14 +0,0 @@
-/**
- * Centralized LAPACK bridge resolution with fallback and one-time logging.
- *
- * Tries the native bridge first; falls back to ts-lapack (pure TypeScript).
- */
-import { type LapackBridge } from "./lapack-bridge.js";
-/**
- * Get the effective LAPACK bridge for a given operation.
- *
- * @param opName  Operation name for logging (e.g. "inv", "qr")
- * @param method  Optional method to check on native bridge. If native bridge
- *                lacks this method, falls back to ts-lapack.
- */
-export declare function getEffectiveBridge(opName: string, method?: keyof LapackBridge): LapackBridge;