No description
Find a file
shoney.arickathil 993a540d7a fix: nullable scalars need their own nil word; EQS accepts nil
Found by running the compiled log-watcher, not by reading code: the supervisor
rejected every cron line ("malformed schedule: * * * * *") because a `*` field
expands to 0 and `?Int`'s nil was also 0, so `a == nil` was true for a real
value. Both log-watcher subcommands now behave: `watch` alerts on a live file,
`run` reports SCHEDULE /var/log/backup.log: * * * * *. corpus 71/0, woc 565/0,
wovm gates green.

- a nullable SCALAR (?Int/?Bool/?Timestamp/?Id) spells nil as WO_NIL_SCALAR
  (-2^62), not the zero word. Heap-shaped optionals keep 0 — a null pointer is
  unambiguous. The value is -2^62 and NOT INT64_MIN on purpose: the compiler's
  integers are OCaml's 63-bit natives, so INT64_MIN is not expressible there
  (and `min_int * 2` silently wraps to 0 — the first attempt did exactly that)
- the class table marks such fields (WOB_FIELD_NIL_SCALAR in field_class), so
  the runtime writes the right absence where it produces absence itself:
  json.decode leaving a key absent or seeing `null`, and parse_int on
  unparseable input (so parse_int("0") is now distinguishable from a failure).
  json.encode renders a nil scalar as JSON null
- emit.ml: `nil` takes its word from its destination (annotation, field,
  return type); a comparison against `nil` emits the literal with the other
  operand's type, so ?scalar compares against the sentinel and ?heap against 0
- vm.c: EQS accepts a nil operand — two `?Text` values compare with it, and the
  answer is "both absent is equal, one absent is not". Trapping there made
  `a != b` on optionals unusable (it was trapping BOUNDS "null text" in the
  supervisor's rescan). A non-nil operand must still be a real Text
- docs: both normative docs now state the heap-vs-scalar nil split and the EQS
  rule; the stale duplicate vm_unwind comment is gone

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-14 17:28:50 +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 fix: nullable scalars need their own nil word; EQS accepts nil 2026-08-14 17:28:50 +02:00
crates remove scrap 2026-08-08 05:01:33 +02:00
docs fix: nullable scalars need their own nil word; EQS accepts nil 2026-08-14 17:28:50 +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 fix: nullable scalars need their own nil word; EQS accepts nil 2026-08-14 17:28:50 +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.