Documentation: English · မြန်မာ · Documentation hub · Language Guide
Zap is a readable, general-purpose programming language with
.zpsource files, indentation-based blocks, optional type checking, explicit modules, structured errors, and a standalone native runtime.
Zap is distributed as a native executable. After Zap is installed, a project can be created, checked, built, tested, and served without installing Python, Node.js, Java, or Rust as application runtime dependencies. HTML, CSS, plain JavaScript, or the built output of React, Vue, Svelte, and other frontend tools can be placed under the project’s public/ directory and served by Zap.
| Item | Status |
|---|---|
| Current release line | v2.11.17 |
| Source files | .zp, commonly main.zp |
| Project manifest | zap.toml |
| Lockfile | zap.lock |
| Runtime | Standalone native executable |
| Platforms | Linux x86_64, Windows x86_64, macOS ARM64 |
| Bootstrap stage | B0 — provisional corpus-limited Zap candidates |
| Reference implementation | Rust native CLI/runtime remains the owner of complete semantics |
| License | MIT |
| Repository | github.com/hidecard/zap |
| Releases | GitHub Releases |
| Current status | Canonical current-status page |
Download the archive matching your operating system and CPU architecture from the v2.11.17 release page, verify its checksum and signature, extract it, and place the zap executable on PATH.
tar -xzf zap-2.11.17-linux-x86_64.tar.gz
cd zap
bash install.sh
zap --versiontar -xzf zap-2.11.17-macos-arm64.tar.gz
cd zap
chmod +x install.sh
./install.sh
zap --versionThe expected archive is zap-2.11.17-windows-x86_64.zip.
cd C:\Zap
install_windows.bat
zap.exe --versionIf you do not have administrator access, keep the executable in a user-owned directory and add that directory to PATH. The complete Language Guide contains platform-specific installation and verification details.
Zap intentionally uses a simple, user-managed project workflow. There is no Django-style startapp command and no hidden app registry.
zap new my_app
cd my_app
zap check
zap build --locked
zap test tests
zap devThe single generator creates the following structure:
my_app/
├── zap.toml
├── zap.lock
├── main.zp
├── web.zp
├── server.zp
├── models/
├── functions/
├── ui/
├── routes/
├── middleware/
├── migrations/
├── admin/
├── public/
└── tests/
These are ordinary user-owned directories. Add, remove, rename, and organize modules directly inside the project as it grows. Use models/ for data shape and validation, functions/ for business logic, ui/ for browser UI metadata, routes/ for HTTP routes, middleware/ for request/response policy, migrations/ for schema changes, admin/ for optional administration registrations, public/ for browser assets, and tests/ for executable checks.
Create hello.zp:
fn greet(name: text) -> text:
return "Hello, " + name
say greet("Zap")Run it with:
zap hello.zp
# or
zap run hello.zplet scores: list<number> = [80, 45, 90]
fn passed(score: number) -> bool:
return score >= 50
for score in scores:
if passed(score):
say "passed: " + str(score)The language includes text, numbers, booleans, lists, maps, objects, functions, classes, inheritance, optional annotations, closures, explicit modules, JSON, Result/Option, default and named arguments, bounded asynchronous tasks, and deterministic diagnostics.
| Need | Start here |
|---|---|
| Install and learn Zap from beginner to advanced | English Language Guide · မြန်မာ Language Guide |
| Searchable syntax reference | English syntax · မြန်မာ syntax |
| Normative language behavior | English specification · မြန်မာ specification |
| Standard library | English index · မြန်မာ index |
| Package and lockfile workflow | English package guide · မြန်မာ package guide |
| Web framework and frontend integration | Zap Web guide · Frontend integration |
| Runtime, memory, and async boundaries | Runtime state · Memory contract · Async boundaries |
| Host adapter and deployment | Host guide · Deployment guide |
| Burmese documentation navigation | မြန်မာ documentation hub |
zap file.zp # run a source file
zap new my_app # create a complete user-managed Web project
zap check . # validate a Zap project directory
zap check --json . # emit structured diagnostics
zap build --locked . # validate reproducible build inputs
zap test tests # run Zap tests
zap fmt main.zp # format source
zap lint main.zp # report style issues
zap lock # generate canonical lock data
zap install # validate locked dependencies
zap update # regenerate lock data after manifest changes
zap web check # validate Web configuration
zap dev # start the bounded development server
zap --help # show all commandsPlain HTML, CSS, and JavaScript work without a JavaScript runtime in production:
<script type="module" src="/assets/app.js"></script>A React, Vue, Svelte, or other frontend project may be built separately and its output copied into public/. Zap serves the resulting files; it does not require npm or Node.js at deployment time. Keep API route declarations in routes/ and browser assets in public/ as described in the frontend integration guide.
The current stable direction covers the .zp language core, native CLI, project manifests and lockfiles, typed checks, modules, classes, Result/Option, JSON, tests, formatter/linter, structured diagnostics, LSP foundations, a user-managed Web scaffold, bounded native Web serving, and SQLite-first migration contracts.
Zap remains at B0. The Zap lexer/parser/type-checker/typed-IR work currently documented under bootstrap/ is provisional and corpus-limited: it provides differential evidence for selected fixtures, while the Rust native implementation remains the reference owner. The B2 function fixtures cover one annotated function, return propagation, a compatible numeric call, and a stable incompatible-call diagnostic; they do not establish a general self-hosted compiler.
Complete type inference, arbitrary-program parser and diagnostic parity, general typed-IR production, package/build ownership, VM execution ownership, and platform-seed acceptance remain future roadmap work. Do not interpret the current candidates as fully Zap-only or B4/self-hosted. The detailed boundary is maintained in the Bootstrap Contract, and broader product scope is tracked in the language specification, contracts, tests, and release notes.
A complete ORM, provider-neutral production migration platform, user-defined trait syntax, production asynchronous I/O reactor, cross-file semantic rename, template compiler, and hidden app registry are not claimed as complete. Their status is tracked in the same specification and release documentation.
Zap itself is implemented in Rust. To build the runtime from source, install the pinned toolchain described by rust-toolchain.toml, then run:
cargo test --manifest-path native/Cargo.toml --all-targets
cargo build --release --manifest-path native/Cargo.tomlBefore contributing, run make doctor to distinguish missing environment prerequisites from test failures, then run the documentation, Web scaffold, release-version, VS Code asset, and LSP parity validators described in the documentation hub. The repository uses master as the integrated baseline; stale merged branches are pruned only after their changes are present in master, while active review branches remain subject to their pull requests. See the branch hygiene and merge record before merging or deleting a branch.
The current source baseline is v2.11.17. The canonical current-status page records the active B0 boundary and the signed provenance fields for the latest published release. The preceding v2.3.0, v2.2.7, and earlier release records remain available in GitHub Releases and the bilingual CHANGELOG files. Release artifacts are published only after version consistency, native tests, cross-platform builds, security checks, documentation checks, and installer verification pass.
Zap is released under the MIT License.