meowy

meowy is a small, composable systems programming language built around values, blocks, emissions, dispatch, and matching.

Its guiding principle is what you write is what you get: data has a concrete representation, allocation has a visible cause, and concurrent work has an owner. The same block vocabulary describes a calculation, a record, a module, or a function body.

The grammar is punctuation-based and has no reserved keywords. true, false, null and types are well-known values and bindings. $ denotes the dispatch receiver; self is an ordinary name. See names and syntax. Undotted numeric spellings can also name value bindings. 10.4 selects field 4 when 10 is bound and otherwise denotes a decimal; @"core".literal(10.4) always requests the number. See numeric names. Spaces are optional: value<T> tests a type and value~<T> explicitly ascribes it. Punctuation can delimit a complete program without whitespace.

<Reading> : <{
    sensor <uint16>
    value <int32>
}>

reading <Reading> : {
    -> sensor : 7
    -> value : 24
}

double <int32> : (value <int32>) {
    -> value * 2
}

sample : {
    -> reading.value.(double)
    -> sensor : reading.sensor
}

sample         # primary value: 48 #
sample.sensor  # named value: 7 #

Emitting does not end execution. A block produces at most one primary value and one value for each emitted name on any execution path. Its fields have a static shape; composing blocks does not require a dynamic object table.

Current version: v0.0.0

v0.0.1 is the first full release target, covering the documented language and ecosystem for the initial supported platform. Full release scope belongs to v0.0.1, not a future v1.0.0. The major and minor numbers have retired; the patch number handles everything. See Versioning, allegedly.

Build, test and install

With the compiler toolchain and verification dependencies installed, run from the repository root:

make test
make build
make install

make test runs documentation, schemas, Vim/Neovim, runtime/sanitizers, Rust/native, Python and debug/release conformance checks. It runs every group, prints a timed table with library/native, Python and required conformance counts, and stores detailed logs in build/verification. Runtime counts appear for debug, release and sanitizer profiles; documentation, catalog and schema results also appear. Known pinned conformance gaps remain visible; unexpected failures return a failing exit status. make test-strict also fails on the known gaps, so it currently fails until those language features are implemented.

make build creates compiler/target/x86_64-unknown-linux-gnu/release/meowy with locked dependencies. make install builds first and installs it as ~/.local/bin/meowy. Add ~/.local/bin to PATH if needed. This host compiler still uses the installed LLVM/Clang/LLD toolchain; it is not a bundled distribution.

Use PREFIX=/path to change the install prefix or DESTDIR=/path to stage an installation. make help lists targets and overrides. For example, make test VERIFY_ARGS=--list previews the checks, and make test VERIFY_ARGS='--timeout 600' changes each check's limit.

Documentation

Start with the guide, or use the documentation index to browse the full reference.

To work on the compiler, read Building the first meowy compiler for the recommended languages, toolchain, architecture, and release gates. Use repository verification to check documentation contracts, editor support, and explicitly selected compiler/runtime checks. The native cleanup prototype exercises ownership cleanup outside the compiler; STATUS.md tracks implementation and remaining work.

For something to build, open Pawterns, the meowy cookbook: 39 recipes from a first greeting through owned buffers, CLI tools, calendar surprises, and getting concurrent work to actually finish.

Topic	What it covers
Syntax	Bindings, literals, operators, functions, and scopes
Values and blocks	Evaluation, emissions, dispatch, matching, and control flow
Types	Inference, unions, narrowing, records, generics, and conversions
Compile-time evaluation	Type-producing helpers, purity, staging, and evaluation budgets
Memory	Ownership, borrowing, allocation, raw pointers, and cleanup
Memory and binary optimization	Storage lifetimes, linker reachability, build policy, and constrained deployment
Collections	Bounded lists, arrays, slices, vectors, and maps
Tasks and channels	Structured concurrency, deadlines, cancellation, and communication
Modules and FFI	Imports, exports, reproducible dependencies, and native boundaries
Package build graphs	Root lock authority, revision identity, and transitive native inputs
Target and native ABI	Initial platform requirements and the explicit C boundary
Standard library	Text, data, collections, time, calendars, system services, and CLI apps
Errors and custom failures	Construct failures, read codes and payloads, preserve ownership, and box explicitly
Testing	Assertions, ordinary suite values, isolated cases, fixtures, and reproducible failures
Diagnostics	Labeled errors, ranked repairs, replay capsules, and failure behavior
Recording and artifact formats	Versioned schemas, reader compatibility, and recorded event contracts
Diagnostic codes	Rule catalog, required evidence, and repair guidance
Command line	Check, build, run, inspect internals, apply fixes, and replay failures
Language server	Editor setup, compatibility, analysis, repairs, and manifest configuration
gatostyle	Configurable layout, code quality, expression styles, and safe fixes

The worked projects put these rules together in 16 self-contained directories, each with its own manifest and run instructions. They cover composition, custom errors, Unicode, JSON, maps, randomness, tasks, channels, timers, calendars, nested CLIs, streaming file tools, and a complete test suite. The design notes explain the choices and the boundaries of the core. The conformance cases pin parsing, typing, ownership, and native-signature decisions with accepted and rejected source fixtures. The time and calendar guide builds toward a small CLI that converts dates between six calendar systems, including Chinese.

Project files

• .mwy files contain meowy source.
• mod.mwy describes imports, local path aliases, exports, build settings, and optional gatostyle and language-server policy. All project language-server configuration lives here. See the manifest guide and its sample.
• Vim and Neovim support provides syntax highlighting, file detection, and buffer settings.

Inspired by Smalltalk, OCaml, Rust, Zig, Go, Lisp, and my cat.

License

Licensed under MPL 2.0