No description
Find a file
shoney.arickathil b973ea107e feat: program mode (argv + exit code); reject + on Text; nil compares by word
docs/examples/log-watcher now COMPILES AND RUNS: `wovm lw.wob watch app.log 2 1`
tails a live file, classifies levels and fires its alert
("last entry is error, quiet for 2s"). corpus 71/0, woc 565/0, wovm gates green.

- program mode: the entry is `fn main` taking nothing or one `multi Text`;
  runtime/src/main.c builds that list from the program's own arguments (not
  the program name, not the image path) and the entry's return value is the
  process exit code (low byte); the loader accepts a 0- or 1-arg free-fn entry
- `+` on Text is now WO-E201 pointing at `..`. This was a memory-safety hole,
  not a style nit: the emitter lowered it to ADD on two heap pointers, and the
  workload's own `out = out + char_of(c)` produced a wild pointer that
  segfaulted the VM inside starts_with. Reported off confident types only
- `x == nil` / `x != nil` lower to EQ (a word compare), never EQS: nil is the
  zero word and EQS dereferences its operands, so a nil guard would trap
  instead of answering
- docs/examples/log-watcher: seven `+`-on-Text sites corrected to `..`
  (logtail sanitize, mcp header/body/carry assembly, supervisor detections
  line) — the sample was carrying the Haxe habit, and the language reserves
  `+` for arithmetic by doctrine
- wovm CLI takes arguments after the image path (`wovm <file.wob> [args...]`)

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-14 17:18:01 +02:00
.dev feat: milestone 1 complete — .wob emitter, conformance corpus, single binary; GC redesign specced 2026-08-11 19:31:26 +02:00
.vscode add wo-rt-c: C runtime prototype, phases A-F shipped 2026-06-12 23:05:13 +02:00
compiler feat: program mode (argv + exit code); reject + on Text; nil compares by word 2026-08-14 17:18:01 +02:00
crates remove scrap 2026-08-08 05:01:33 +02:00
docs feat: program mode (argv + exit code); reject + on Text; nil compares by word 2026-08-14 17:18:01 +02:00
infra scaffold sibling crates, multi-app ecommerce, REST + concurrency docs 2026-05-04 13:39:58 +02:00
prototypes/wo-db remove scrap 2026-08-08 05:01:33 +02:00
runtime feat: program mode (argv + exit code); reject + on Text; nil compares by word 2026-08-14 17:18:01 +02:00
scripts feat(compiler): iteration 5 Tasks 1-4 — modules, language surface, switch, typedef records + enum variants 2026-08-12 14:40:07 +02:00
static scaffold sibling crates, multi-app ecommerce, REST + concurrency docs 2026-05-04 13:39:58 +02:00
templates scaffold sibling crates, multi-app ecommerce, REST + concurrency docs 2026-05-04 13:39:58 +02:00
tests/corpus feat: systems stdlib OS half — fs, time, env, net, proc 2026-08-14 16:54:31 +02:00
.gitignore feat: milestone 1 complete — .wob emitter, conformance corpus, single binary; GC redesign specced 2026-08-11 19:31:26 +02:00
.gitmodules begin 2026-04-05 00:45:02 +02:00
Cargo.lock add http runtime 2026-05-04 23:50:16 +02:00
Cargo.toml abstract syntax tree and parser prototype 2026-04-21 03:28:25 +02:00
CLAUDE.md add skills as symlinks 2026-08-08 05:33:19 +02:00
justfile feat: milestone 1 complete — .wob emitter, conformance corpus, single binary; GC redesign specced 2026-08-11 19:31:26 +02:00
prompt.md next oer board 2026-07-12 05:47:40 +02:00
README.md add skills as symlinks 2026-08-08 05:33:19 +02:00

writeonce

A declarative full-stack programming language. You write .wo files; the runtime compiles them into a binary that owns the database, serves REST, and pushes live subscriptions — no external database, no external web server, no frontend framework.

Think Go + Postgres + net/http + Phoenix LiveView, folded into one language and one binary.

persistant database

  • reads and writes database to RAM, persist data to postgres SQL.
  • The entire database lives in RAM; every committed write is mirrored to PostgreSQL as a backup — asynchronously, behind the runtime's own WAL, never in the read or ack path. Set WO_PG=postgres://user@host:5432/db and every type's rows appear as a Postgres table (named by its @table(name: ...) annotation) that you can query with plain psql. Plan and phases: docs/plan/16-postgres-mirror.md; try it: just pricing-pg-demo.

Quickstart

git clone https://github.com/shoneyJ/writeonce
cd writeonce
cargo run --bin wo -- run docs/examples/blog     # serve the sample blog on :8080
curl http://127.0.0.1:8080/api/articles          # it's a real REST API now

See .dev/reference/rest/blog.rest for a preconfigured HTTP-request file that drives the whole sample — open it in VS Code (with the REST Client extension) or JetBrains and click "Send Request" on each block.

What this repository contains

Path What it is
crates/rt/ The new .wo language runtime — lexer, type-DSL parser, in-memory engine, axum REST server. Produces the wo binary.
crates/{ql,value,engine,txn,db,wal,sub,http,gen,policy,logic,service,ui,app}/ 14 empty placeholder crates scaffolded for Phases 2–6. Real code extracts from rt/ as each phase activates.
docs/runtime/wo-language.md Start here. The language overview: toolchain, hello-world, stdlib, client model.
docs/runtime/database.md The 7-phase engineering series that drives the runtime's design.
docs/examples/blog/ Sample .wo project: blog with articles, authors, tags, comments. ~200 lines.
docs/examples/ecommerce/ Sample .wo project: storefront + live order-ops table + cross-paradigm checkout. ~300 lines.
prototypes/wo-db/ C++ prototype of the query-layer engine (SQL + Cypher + document paths, RETURNING aliases, LIVE stub). ~2k lines, smoke tests pass. Reference implementation the Rust port follows.
.dev/reference/rest/ .rest files (VS Code REST Client / JetBrains HTTP format) for manually testing the running prototype.
.dev/reference/crates/ The v1 writeonce blog — 13 Rust crates implementing the original .seg + sidecar-index storage engine and .htmlx templating. Preserved as a nested workspace; see .dev/reference/README.md.

Current stage

The runtime is under active development. Each stage lands as an independently shippable cut:

Stage What works Status
1 wo run <dir> discovers every .wo file under a directory ✅ shipped
2 Type-DSL parser, in-memory engine, REST CRUD (list / get / create / update / delete) generated from service rest blocks, JSON bodies with auto-id, default-value seeding, partial-update PATCH ✅ shipped — cargo run -- run docs/examples/blog
3 LIVE subscriptions over WebSocket, delta frames on commit, me / session layer pending
4+ Transactional fns (fn checkout in txn snapshot), row-level policies, type-attached triggers, ##ui SSR, WAL durability, codegen see docs/runtime/database.md

cargo test --lib at the root runs 14 unit tests covering the lexer, parser, compiler, and engine. Stage-3 endpoints respond 501 Not Implemented until they land.

Build & test

cargo build                                         # builds all 15 crates (only `rt` has real code)
cargo test --lib                                    # 14 unit tests

cargo run --bin wo -- run docs/examples/blog       # serve the blog sample
cargo run --bin wo -- run docs/examples/ecommerce  # serve the ecommerce sample

# Override the listen address
WO_LISTEN=127.0.0.1:9000 cargo run --bin wo -- run docs/examples/blog

The v1 codebase (reference)

The original writeonce blog engine — 13 crates, flat-file .seg storage, sidecar indexes, .htmlx templates, hand-rolled epoll event loop — moved to .dev/reference/crates/ when the new runtime was scaffolded. It's a nested Cargo workspace:

cd .dev/reference/crates
cargo build                   # all 13 v1 crates still compile
cargo test                    # 12 unit tests, 1 ignored integration test

V1 crates keep the wo- prefix (wo-seg, wo-store, …). The new runtime crates dropped it (ql, value, engine, …). docs/runtime/database/07-wo-seg-migration.md is the phased coexistence plan for replacing v1 with the new runtime — abstract behind a trait, dual-write, cut over, decommission.

License & status

Work in progress. Nothing here is stable. Read the language overview in docs/runtime/wo-language.md if you want to know the shape; read the phase docs if you want to see the engineering plan; look in docs/examples/ if you want to see what the end product feels like.