Implementation Roadmap

Relevant source files

The following files were used as context for generating this wiki page:

• AGENTS.md
• README.md
• architecture/22.6-standard-library-implementation-plan.md
• assets/pop_dsl_blocks_design_prompt.md
• architecture/decisions/0028-toolchain-distribution-and-popup-management.md
• architecture/README.md

The Pop Lang implementation roadmap outlines the structured progression from architectural design to a stable, production-ready native programming language. As an architecture-first project, Pop Lang follows a mandatory workflow where design gaps are closed and tests are established before any feature implementation occurs. The roadmap is divided into thematic phases covering the core compiler, the standard library, toolchain management, and advanced language features like DSL blocks.

The project prioritizes maintaining a "Luau-shaped" identity—lightweight and readable—while enforcing strict static typing and a native runtime model that avoids Lua's dynamic table-centered architecture.

Sources: AGENTS.md:14-35, README.md:16-30, architecture/README.md:131-135

Core Development Workflow

Every feature implementation follows a strict, non-negotiable loop. This ensures that the code remains a faithful representation of the accepted architecture and prevents "syntax drift" or the introduction of dynamic fallback mechanisms.

Standard Library Implementation Plan

The public library (specifically Pop.Standard) is implemented in nine distinct phases. Each phase must clear specific gates, including cost/effect schema validation and performance benchmarks, before stabilization.

Phase	Focus Areas	Key Deliverables
0. Baselines	Prelude, Architecture Tests	Exact root/tier manifests, docs cost/effect schema.
1. Core Values	Math, Random, Text, Bytes	Unicode-safe slicing, numeric boundaries, allocation fixtures.
2. Formats	Json, Yaml, Xml, Time	Streaming primitives, locale data, YAML resource compiler.
3. I/O & Host	File, Process, Terminal	PLRI adapters, fault injection, sandbox/capability review.
4. Concurrency	Task, Channel, Net, Http	Actor isolation, TLS/HTTP, backpressure tests.
5. Data	SQL, Telemetry, CLI	Extension manifests, driver contract suites, query benchmarks.
6. Tooling & RPC	Syntax, LSP, FFI, Test	Protocol compatibility, ABI/callback/GC-root tests.
7. Media	Image, Audio, UI, Tensor	Headless UI snapshots, frame/buffer lifetime tests.
8. Distributed	Cluster, Device, Ai	Identity/auth safety, device permission matrices.

Sources: architecture/22.6-standard-library-implementation-plan.md:8-27

Initial Library Slices

To establish reusable conventions, the first implementation pull requests focus on foundational infrastructure:

1. Manifest Schema: Defining tier/status/capability metadata.
2. Modular Source-Library Build: Enabling ordinary .pop modules to compile for Pop.Standard.
3. Extension Packages: Bootstrapping Pop.Data, Pop.Ai, and Pop.Lsp.
4. Prelude Baseline: Fixing primitive bindings and the Sequence root.

Sources: architecture/22.6-standard-library-implementation-plan.md:39-55

Toolchain & Distribution Roadmap

The distribution system is managed by a dedicated tool called popup, which is separate from the main pop language command. This ensures a clean boundary between the language's package management and the toolchain's versioning.

Release Pipeline Requirements

A production release requires several verification stages:

• Immutable Source: Releases are built from an exact source revision.
• Artifact Reproduction: Distributions are reproduced in clean builds to verify digests.
• Smoke Tests: Executables must run popup doctor and compiler checks outside the source checkout.
• Signed Metadata: The stable pointer is only updated after all host artifacts are verified.

Sources: architecture/decisions/0028-toolchain-distribution-and-popup-management.md:14-45, architecture/decisions/0028-toolchain-distribution-and-popup-management.md:255-275

DSL and Block System Progression

The design for DSL blocks follows an incremental MVP to ensure zero-cost abstraction and static safety without inheriting Ruby or Crystal's dynamic ambiguity.

MVP Phases for Blocks

1. Phase 1: Typed Trailing Blocks: Support for do ... end and single-expression { ... } with exact arity and inferred types.
2. Phase 2: Collection APIs: Implementation of each, map, and reduce with no-allocation guarantees.
3. Phase 3: Scoped Receivers: Adding scoped Receiver contracts to allow leading-dot shorthand (e.g., .listen(8080)) in builders.
4. Phase 4: Explicit Procs: Introducing first-class callable proc literals with explicit capture and lifetime rules.
5. Phase 5: Typestate & Effects: Advanced builder validation and effect-aware block contracts.

Sources: assets/pop_dsl_blocks_design_prompt.md:586-630

Implementation Invariants

Regardless of the phase, the following architectural invariants must remain active:

• Static Typing: No Any or Dynamic escape hatches are permitted.
• Backend Neutrality: HIR and MIR must contain no LLVM-specific objects or layouts.
• Ownership Hierarchy: All code must respect the Item → Module → Bubble → Package → Workspace structure.
• Lua Regression Prevention: The language must not revert to table-centered semantics or runtime string resolution.

Sources: AGENTS.md:24-35, architecture/README.md:112-118, README.md:195-208

---

The Implementation Roadmap ensures that Pop Lang evolves from its current Rust-based foundation into a self-hosting ecosystem with a robust standard library and verified native backends. Each milestone is governed by the Architecture Conformance policy, ensuring the language's identity remains consistent across its development lifecycle.