Share stdlib type-checking within one skc invocation (batch / multi-file mode)
Follow-up to #1295, which measured that type-checking the stdlib is ~3.15s ≈ 64% of every compile, redone identically on every invocation.
Why this is (almost) free
The typed stdlib is already a per-definition, reactively-memoized pure function of source — the frontend is a chain of SKStore .maps (src/skipMain.sk type_program: source → parse → name → /typing/), each typed def is its own keyed cell, and cross-def references are tracked read edges. SKStore already refuses to recompute a key whose inputs are unchanged. It's re-typed every run only because skc creates a fresh empty SKStore.Context::create{} per process (src/main.sk:123) and discards it at exit.
So within a single process, reusing one Context across N compilations types the stdlib once: the first file types it; for files 2..N, pkgDelta (src/skipParse.sk:83-149) sees the unchanged stdlib package and writes nothing, so context.update() re-runs only the arrows reachable from each new input. The ~64% stdlib cost is paid once, not N times.
Prior art (this already works)
Both prove the mechanism; neither left a supported general CLI for it.
What to build
A supported multi-file / batch entry point that compiles several inputs in one process without recreating the context per file — i.e. loop compile() (or an equivalent) over the input set on a single Context, or accept a manifest of (inputs, outputs, mainFn). The engine (dirty-tracking Context.update loop; delta writeFiles) already does the rest.
Payoff / scope
- Payoff: eliminates the constant stdlib re-type for every file after the first within one invocation — whole-crate and whole-suite builds. Effort: small (mostly a CLI/driver change; no new engine work).
- Scope limit: this only helps within one process. It does not speed up separate
skc invocations (incremental edit/rebuild of a single file across processes) — that's the companion approach: persist the warm context across invocations (sibling issue).
🤖 Generated with Claude Code
Share stdlib type-checking within one
skcinvocation (batch / multi-file mode)Follow-up to #1295, which measured that type-checking the stdlib is ~3.15s ≈ 64% of every compile, redone identically on every invocation.
Why this is (almost) free
The typed stdlib is already a per-definition, reactively-memoized pure function of source — the frontend is a chain of SKStore
.maps (src/skipMain.sktype_program: source → parse → name →/typing/), each typed def is its own keyed cell, and cross-def references are tracked read edges. SKStore already refuses to recompute a key whose inputs are unchanged. It's re-typed every run only becauseskccreates a fresh emptySKStore.Context::create{}per process (src/main.sk:123) and discards it at exit.So within a single process, reusing one
Contextacross N compilations types the stdlib once: the first file types it; for files 2..N,pkgDelta(src/skipParse.sk:83-149) sees the unchanged stdlib package and writes nothing, socontext.update()re-runs only the arrows reachable from each new input. The ~64% stdlib cost is paid once, not N times.Prior art (this already works)
@exptestharness (Dual-mode compiler test harness: unified @exptest mode with subprocess fallback #1289, merged) compiles all test.skinto oneskcinvocation = oneContext= one stdlib typing.compile()calls (SKC_BATCH).Both prove the mechanism; neither left a supported general CLI for it.
What to build
A supported multi-file / batch entry point that compiles several inputs in one process without recreating the context per file — i.e. loop
compile()(or an equivalent) over the input set on a singleContext, or accept a manifest of(inputs, outputs, mainFn). The engine (dirty-trackingContext.updateloop; deltawriteFiles) already does the rest.Payoff / scope
skcinvocations (incremental edit/rebuild of a single file across processes) — that's the companion approach: persist the warm context across invocations (sibling issue).🤖 Generated with Claude Code