Backlog

This is the single maintained list of remaining language, compiler, runtime, standard-library and tooling work. Entries are candidates, not promises about syntax or delivery dates. Row order is a catalogue, not a priority list.

Delivered milestones and retired entries live in Completed work. A B ID can appear there for its delivered subset and here for its remaining extensions; IDs are never renumbered or reused. The implementation status and reference describe what works today. Proposals record rationale and alternatives, not another work queue.

The experimental Windows x86-64 dataframe build and release packaging are recorded in completed work. The macOS ARM64 dataframe subset is recorded in completed work. Broader native OS qualification remains in B18.7.

Current position

B34’s bounded cleanup/review, B71’s typed HTTP acceptance batch, B76’s initial dataframe datatype expansion, the initial B39–B70 library slices and B17 package tooling have landed. Their delivery records are in Completed work. Preserve their installed-toolchain, CLI/data, JSON-service, mutual-TLS and HTTP qualification checks during further work.

Issue severity takes precedence over the batches below. Defects, reproductions, claims and implementation/review status belong in the shared issues.db. Nothing on this page assigns ownership or approves an API without a scoped agreement and acceptance checks.

Next batches

• B76 — analytical workloads: decimal columns follow the std.decimal proposal after its core module ships. Use the pinned Polars engine’s Parquet capabilities; fixed-size arrays, dictionary semantics, nested casts and broader list operations need separate scope. Use the daily sales application and examples/sales_report/ as evidence: truly large or rejection-heavy workloads should guide multi-output streaming. Temporal/grouped as-of matching and time-bucketed/rolling aggregations need a separate workload before expanding the API.
• B23/B76 — measured SIMD extensions: packed views, wider shapes, broader predicates, maps/folds, runtime ISA selection and parallel scans need bounded legality/performance evidence. Account for code placement using the retained placement research.
• B71 — additive error ergonomics: reporting conveniences remain independent candidates, not prerequisites for typed HTTP composition.

Further library breadth, B11 stored-reference extensions and B72 state/linear-obligation experiments remain candidates requiring a concrete use case and an agreed contract. This sequence preserves the existing batch scope; it does not schedule all catalogue entries.

Deliberate deferrals

• B19 — module caching and frontend scale: serial efficiency, streaming lowering/emission and per-module caching need measurements and a focused batch. The module-cache investigation rejected separately compiled modules and stored syntax trees. A lowered-module cache needs imported interfaces and invalidation by body-derived facts; its broad-import benchmark offered about 30 ms of frontend work in a 44 ms body-edit build. Revisit for frontend-bound std-heavy applications, using module-edit measurements as the baseline. Remote caching waits on a local per-module contract.
• B22 — broader concurrency: richer mapping/effects, streaming results, rendezvous, larger or send-side selection remain deferred. Existing channel and executor checks do not establish deadlock freedom.
• Automatic parallelization (B24), optional backends (B20), stored-reference relationships (B11), broader callback erasure (B32) and automatic deep recursive operations (B33) require their own contracts and acceptance checks.

Scope of follow-on work

B22 — task models. The stackful-task investigation and async/await exploration do not commit Plenty to either implementation. Before adoption, compare the same bounded TCP/HTTP workload: I/O cancellation/registration lifetimes, allocation and failed-start preservation, stack budgets, suspension/loan checks, memory and latency. Fixed stacks trade pinning/relocation for reservations and fatal unchecked exhaustion. Retaining native concurrency remains an option. Prefer library APIs over new syntax; require bounded queues/backpressure, failed-send ownership, joins on all exits, cooperative cancellation and partial-result cleanup. Scoped generic tasks need not wait for heterogeneous callback storage in B32.

B32 — additional callback representations. Evaluate registry/event-handler use cases and specify invocation, move/drop, allocation failure and capture lifetimes before adding erased modes. Escaping borrowed captures depend on B11; C ABI callbacks and foreign-library lifetimes remain B28.

Work items

Language, compiler and tooling

Tooling investigations

These belong to B17 and are not scheduled implementation commitments:

• Compiler boundaries: structured diagnostics, scoped recorder/teardown policy, the op and syntax-layer splits and grouped pipeline state are delivered (issues #691–#695). A compilation session and further lowering-state extraction wait for a consumer. Module replay remains B19, not a wholesale frontend rewrite.

• Single-file script manifests, isolated dependency resolution, durable locks and argument forwarding are delivered. Warm executable hits also skip runtime extraction (issue #699). Broader executable-cache toolchain coverage remains B17/B18; a script test command would require its own entry-point/discovery design.

• plenty-manager: a Plenty-written tool in a separate plentylang/plenty-manager repository for compiler installation, explicit updates, side-by-side versions and project pins. Settle release authentication and qualify manager hosts before delivery.

• Language editions: wait for a concrete incompatible change; prove mixed-edition compilation with shared types/runtime before edition or migration tooling.

• Rust crate dependencies: three prototypes compare Rust ABI, generated C adapters and Rust-source lowering. The next gate is real Plenty project integration with checked foreign owners and a coherent runtime build; generated C adapters are the proposal’s recommendation.

• Local semantic search: improve chunk boundaries and measure retrieval quality before deciding on committed index snapshots. Prefer Plenty for the interface and record language defects in issues.db.

Remaining performance work

B19 is evidence-driven; these are candidates, not an approved optimization batch. Use profiling, faster-linking evidence and the completed measurements as baselines.

• Generated code: retain/release for text operands computed by calls or loaded in another block; dispatcher copies of sums with inline-record payloads; code size and compilation/link latency. Revisit match density/size policies only with application/CPU evidence. An opt-in CPU target such as x86-64-v2 requires a decision against B17’s fixed-baseline reproducibility contract.
• Layout/cleanup: natural record-field packing beyond 16-byte slots, compact sum tags/niches, relocation/release plans for records holding ranges/sums/other managed fields, records over 192 bytes and tuple release plans. Measure inline copies beyond current runtime-copy paths; owned temporaries and nonscalar list rows still use runtime helpers. Flat-layout rationale. Box size (issue #814): a box’s class-record slot still keeps a value word that only addresses the record after it, and Option[Box[T]] keeps a tag word rather than a null niche; dropping both would take a binary-trees node from a 96-byte malloc chunk to 64 (C: 32). A size-class free list for fixed-size boxes is unmeasured.
• Serial frontend efficiency: module-scope name hashing, builtin-sum interning and Ty/nominal-handle clone traffic (about 10% of check samples with allocation excluded; issue #696). The signature map and nominal fact/lock costs measured below 2% and are not candidates. Whole-program table/cache misses still increase per-function cost at scale (issue #57); interned names or per-function batch processing need measurements. Further type-representation changes follow the completed issue #302 investigations. Measured attribution records the profile; existing frontend function symbols and type-fact caches are not missing features.
• Peak memory: lower and emit one function at a time instead of retaining full syntax/operation sets at phase boundaries (issue #54). IR construction’s measured 7% of emission CPU limits scaling only above about fourteen cores.
• Caching/lowering: imported-interface lowering with explicit outputs and serialized operations/types; body-derived invalidation and per-function granularity for one-module programs (issue #317). Separately evaluate lowering only reachable std functions. A trusted opt-in remote cache follows a local per-module contract, not before it. Prove fresh-environment replay using explicit module outputs before persistence. See deferrals.
• Upstream gates: regalloc2’s quadratic block-parameter handling needs an upstream report/fix before removing the 2,048-argument fallback. Reopen issue #425’s deferred arithmetic-check work only when Cranelift changes unfused overflow branches, frame setup or callee-save spills; do not treat closed investigations as active claims.

Stdlib-driven language ergonomics

Units of measure

Runtime-independent protocol support

Standard library follow-ups

Only outstanding extensions are listed here. Initial delivery records, issue/PR references and reference links live in Completed library work. B IDs keep their original scope; a closed initial issue does not approve a follow-up. All candidates still require scope and acceptance checks.

Reconciled completed work

The delivery records and retired entries moved to Completed work. This heading remains as a link destination; completed-only B IDs no longer appear as work to select here.

Keeping this list useful

• Add, prioritize or split future work here. Keep IDs stable and link design detail rather than copying queues into proposals, tutorials or reference pages.
• Settle a candidate’s scope and acceptance checks before implementation. Table order does not approve APIs or require every extension.
• Before syntax/builtins, state the user problem, why ordinary library code is insufficient, and ownership, allocation, compilation and teaching costs.
• On completion, move the delivered scope to Completed work, update reference/status/runnable lessons, and leave only genuine outstanding extensions here with a link to their delivery record. Do not mark an entire mixed item done because its initial slice shipped.
• Issues, claims and review state stay in issues.db; reference pages describe implemented behavior. Use the development workflow for ongoing testing, documentation and performance practices.
• Historical proposals may contain old syntax/dependencies; introductory notices must say so. Future priorities belong here, not on completed-work pages.

A JIT and an interpreter remain out of scope, not waiting at the bottom of this backlog. Async/await remains unadopted and unscheduled under B22’s investigation gates.

B18 — macOS and Windows implementation sequence

The portability design records rationale and toolchain evidence; this section owns the work sequence. Target ARM64 macOS and x86-64 Windows, preserving both Linux architectures. Use isolated child worktrees based on the portability branch, with component ownership agreed before concurrent edits. No local Mac/Windows machine is assumed; provision CI execution before treating either port as tested.

Current evidence: the native CI smoke suite passes on macOS ARM64, Windows x86-64 MSVC and Linux x86-64. The first B18.2 increment centralizes target facts and compiler-host/runtime validation; it does not implement new object formats or OS services. This is a partial B18.1 gate: large frames, unwind, Rust boundaries and runtime dependencies still need qualification. Both new OS targets are experimental; neither is release-qualified. The shared Apple archive-command fix addresses issue #600; native build-tool tests run before the OS port build and on both Linux architectures. The first B18.5 increment separates native mutex waiting and thread handles, hides cancellation wake storage, and adds Darwin signal-context and stack-handler support. Standalone native synchronization tests run before the complete compiler build. Windows exception dispatch and per-thread stack guarantees are implemented with standalone subprocess tests that pass on the native Windows runner. Native OS entropy fixes dictionary initialization on non-Linux hosts (issue #604); Windows no-replace bundle publication and portable graph fixtures address issues #605 and #606. The initial B18.3 increment enables experimental Mach-O/COFF application output, native C conventions and linker syntax, with framed Mach-O interface metadata. Native qualification now passes full compiler/runtime builds, unit tests, platform-boundary checks and generated-program callback/result probes on macOS ARM64 and Windows x86-64. Linux x86-64 and ARM64 CI also passes all integration shards, both optional engines and Docker proxy tests. Full new-OS standard-library parity and release admission remain gates; these results do not complete B18.5–9.

B18.1 and B18.6 design research can run together; B18.3 and B18.4 can proceed in separate worktrees after the common description settles. Keep independent OS implementations separate after their contracts are agreed. A failing native probe changes the design before target admission. User-facing cross-compilation, Intel macOS and Windows ARM64 remain separate decisions, not implied outcomes.