@fraczak/k 7.0.0 → 7.0.2

package/CHANGELOG.md

@@ -5,6 +5,56 @@ All notable changes to this project will be documented here.
 The format follows [Keep a Changelog](https://keepachangelog.com/en/1.0.0/).
 This project uses [Semantic Versioning](https://semver.org/spec/v2.0.0.html).
 
+## [7.0.2] — 2026-10-13 — LLVM Squaring Scaling & Backend Streamlining
+
+### Features & Performance Improvements
+
+- **Multiplication Algorithm Scaling Benchmark (LLVM & Multi-Backend)**:
+  - Added successive squaring scale benchmark comparing standard long
+    multiplication (`times`) and Karatsuba multiplication (`karatsuba`)
+    across bit lengths doubling up to 7,650+ bits.
+  - Added support for squaring execution and memory (peak RSS / heap)
+    tracking across LLVM, WebAssembly, and interpreter lanes.
+  - Aligned product field layouts and offset indexing in `kvm2llvm.mjs`.
+
+### Bug Fixes & Compatibility
+
+- **LLVM Open/Closed Pattern Compatibility on Wire Input**:
+  - Allowed open and closed pattern compatibility when validating and
+    unpacking wire inputs in the LLVM runtime (`krt.c` and
+    `executable.mjs`).
+  - Gracefully accepts framed inputs matching open-product schemas.
+
+### Chores & Maintenance
+
+- **Backend Streamlining (Wasm & LLVM Focus)**:
+  - Removed legacy experimental ARM64 backend (`backends/arm64`) to focus
+    on WebAssembly (portable) and LLVM (native) backends.
+  - Updated documentation (`DOCS/FILE_FORMATS.md`,
+    `DOCS/PROFILING_AND_TRACING.md`) and benchmark suites.
+  - Enhanced pattern graph specialization and KIR monomorphization in
+    `kir.mjs`.
+
+## [7.0.1] — 2026-10-10 — Call-Graph Pattern Graph Specialization
+
+### Bug Fixes & Backend Alignments
+
+- **Pattern Graph Specialization Across Call Graphs**:
+  - Implemented `specializeObjectRelations` in `kir.mjs` to propagate input
+    schemas across relation call graphs via monomorphization.
+  - Statically resolves field projection offsets for open product and
+    polymorphic helper relations without dynamic fallback (`@k_product_get_n`).
+  - Fixed WASM predicted field index calculation and aligned product header
+    memory layout (`tagId` at header slots).
+  - Resolved polymorphic list and open product projection alignment across
+    LLVM, WASM, and Web REPL.
+- **Filter Relation Naming Convention (`?` Suffix)**:
+  - Standardized naming convention for all filter and schema relations to use
+    the `?` suffix (e.g. `int?`, `bits?`, `bit?`, `string?`, `pattern?`,
+    `bnat?`, `nat?`, `bool?`, matching `list?`).
+  - Separated integer filter schema `int? = ?<...>` from constructor
+    `int = nat | '+'` in `Examples/arithmetics.k`, removing symbol collision.
+
 ## [7.0.0] — 2026-10-10 — Unified Schemas, Relational Contracts, and Pure Syntax
 
 ### Breaking Language & Syntax Changes

package/DOCS/BIG_PICTURE.md

@@ -49,7 +49,7 @@ set of pairwise distinct labels `l1, l2, ..., ln`:
 - Variant values are constructed using "|" (pipe) followed by the tag:
   - Unit variant: `{} | nil`, `{} | zero`
   - Variant with payload `v` at tag: `v | tag`
-- Example (list): with `list = ?< {} nil, { X car, L cdr } cons > = L;`:
+- Example (list): with `list? = ?< {} nil, { X car, L cdr } cons > = L;`:
   - Empty list `[]`: `{} | nil`
   - Singleton `[v]`: `{ v car, {} | nil cdr } | cons`
 - Angle brackets `< ... >` denote ordered choice (union expressions); use
@@ -202,14 +202,14 @@ The contract derivation steps are:
 #### Example 1
 
 ```text
-bit = ?< {} o, {} i >;
+bit? = ?< {} o, {} i >;
 bit0 = | o;
 bit1 = | i;
 
-byte = ?{ bit b0, bit b1, bit b2, bit b3 };
+byte? = ?{ bit? b0, bit? b1, bit? b2, bit? b3 };
 zero = bit0 { () b0, () b1, () b2, () b3 };
 
-inc = byte
+inc = byte?
    <
       { bit0 overflown,  { .b0 /o bit1 b0, .b1  b1,  .b2 b2,  .b3 b3 } byte }, 
       { bit0 overflown,  { bit0 b0, .b1 /o bit1 b1,  .b2 b2,  .b3 b3 } byte },
@@ -347,7 +347,7 @@ conversion via `5 int`.
 Bit trees are defined algebraically:
 
 ```text
-bits = ?< {} _, B 0, B 1 > = B;
+bits? = ?< {} _, B 0, B 1 > = B;
 ```
 
 ### Literals for `@bits` are:

package/DOCS/FILE_FORMATS.md

@@ -288,12 +288,12 @@ Export all currently loaded relations and types into a reusable library:
    `make_variant`, `project_variant`, `jump_if_fail`, `call`, and loops).
 
 2. **$1 \times N$ Backend Decoupling:**
-   Rather than having every code generator (LLVM, WebAssembly, ARM64,
-   and the JIT interpreter) independently lower the relational tree and
+   Rather than having every code generator (LLVM, WebAssembly, and the
+   interpreter) independently lower the relational tree and
    re-implement type-guided control flow, relational-to-imperative
    lowering occurs once in `kvm.mjs`. All backends consume the exact same
    ~10 linear kVM instructions (`kvm2llvm.mjs`, `kvm2wasm.mjs`,
-   `kvm2arm64.mjs`, `kvm.mjs`).
+   `kvm.mjs`).
 
 3. **Microsecond Polymorphic Specialization (`layer: "KVM-P"`):**
    In polymorphic programs, specializing `.ko` requires re-running the
@@ -398,9 +398,9 @@ In `k`, there are no primitive numerical types or built-in integer
 literals. Identifiers such as `5` or `10` are not language keywords;
 they are defined relations (aliases) in `Examples/arithmetics.k`:
 - `5` and `10` are nullary relations (constants) of type `{} -> bits`,
-  defined as binary digit trees over `bits = ?< {} _, bits 0, bits 1 > = bits;`.
+  defined as binary digit trees over `bits? = ?< {} _, bits? 0, bits? 1 > = bits?;`.
 - Arithmetic operations (`plus`, `minus`, `times`, `inc`) operate on
-  signed integers (`int = < <bits 0, bits 1, {} _>=bits "+", bits "-" >`).
+  signed integers (`int? = ?< <bits 0, bits 1, {} _>=bits "+", bits "-" >`).
 - Passing a bit-representation like `5` to an integer relation requires
   applying the `int` constructor (`5 int`), producing a constant
   relation of type `{} -> int`.

package/DOCS/OBJECT_FILE_AND_PATTERN.md

@@ -15,18 +15,18 @@ The pattern is the framing protocol. There is no separate envelope type.
 [`core.k`](../core.k) defines the canonical self-hosted pattern type:
 
 ```k
-edge = ?{ string label, bits target };
-edges = ?< {} nil, { edge car, E cdr } cons > = E;
+edge? = ?{ string? label, bits? target };
+edges? = ?< {} nil, { edge? car, E cdr } cons > = E;
 
-pattern-node = ?<
+pattern-node? = ?<
   {} any,
-  edges open-product,
-  edges open-union,
-  edges closed-product,
-  edges closed-union
+  edges? open-product,
+  edges? open-union,
+  edges? closed-product,
+  edges? closed-union
 >;
 
-pattern = ?< {} nil, { pattern-node car, P cdr } cons > = P;
+pattern? = ?< {} nil, { pattern-node? car, P cdr } cons > = P;
 ```
 
 This does not mean `core.k` is pre-loaded into ordinary program execution. The
@@ -274,7 +274,7 @@ For a definitions-only source file:
 
 ```k
 -- defs.k
-nat = ?< {} zero, N succ > = N;
+nat? = ?< {} zero, N succ > = N;
 succ = |succ;
 ```
 

package/DOCS/PATTERNS.md

@@ -56,9 +56,9 @@ A k script can describe a pattern through:
 Examples:
 
 ```k
-bits = ?< {} _, bits 0, bits 1 > = bits;
-list = ?< {} nil, { < {} _, B 0, B 1 >=B car, L cdr } cons > = L;
-list
+bits? = ?< {} _, bits? 0, bits? 1 > = bits?;
+list? = ?< {} nil, { < {} _, B 0, B 1 >=B car, L cdr } cons > = L;
+list?
 ```
 
 ```k

package/DOCS/PROFILING_AND_TRACING.md

@@ -5,7 +5,6 @@ and function-level call profiling infrastructure for `k` backends.
 
 The profiling framework allows fine-grained performance analysis of polymorphic `k`
 programs across multiple execution targets:
-- **Linux ARM64** (native standalone ELF executable via direct kVM assembly emission)
 - **WebAssembly** (in-process Wasm module via single-pass kVM lowering)
 - **LLVM** (native specialized executable via KIR-P lowering)
 - **kVM Interpreter** (in-process TypeScript/JavaScript kVM evaluator)
@@ -15,17 +14,23 @@ programs across multiple execution targets:
 
 ## 1. Motivation: Apples-to-Apples Backend Comparison
 
-When measuring end-to-end request latency across backends, wall-clock time can be
-dominated by factors outside the core relation algorithm:
-- **Process IPC**: Out-of-process native executables (ARM64, LLVM) communicate via stdin/stdout pipes, incurring OS context switches and pipe buffer copies.
-- **Wire Codec**: Decoding and validating the binary wire format (`pattern + value`) and encoding the response.
-- **In-Memory Representation**: WebAssembly converts incoming values into a flat linear memory arena layout.
-- **Pure Evaluation**: The actual relational instruction loop performing the algorithm.
-
-Without detailed accounting, native ARM64 or LLVM binaries communicating over pipes can
-appear slower than in-process WebAssembly or the interpreter simply because of IPC overhead.
-The tracing infrastructure breaks request latency down into nanosecond-level phases so that
-pure execution time can be measured and compared directly.
+When measuring end-to-end request latency across backends, wall-clock
+time can be dominated by factors outside the core relation algorithm:
+- **Process IPC**: Out-of-process native executables (LLVM)
+  communicate via stdin/stdout pipes, incurring OS context switches and
+  pipe buffer copies.
+- **Wire Codec**: Decoding and validating the binary wire format
+  (`pattern + value`) and encoding the response.
+- **In-Memory Representation**: WebAssembly converts incoming values into
+  a flat linear memory arena layout.
+- **Pure Evaluation**: The actual relational instruction loop performing
+  the algorithm.
+
+Without detailed accounting, native LLVM binaries communicating over
+pipes can appear slower than in-process WebAssembly or the interpreter
+simply because of IPC overhead. The tracing infrastructure breaks
+request latency down into nanosecond-level phases so that pure
+execution time can be measured and compared directly.
 
 In addition, **per-function invocation profiling** verifies that every backend performs the
 exact same number of relational evaluations and loop iterations for a given input.
@@ -56,37 +61,41 @@ Following `k`'s canonical content-addressed design:
 
 When tracing is enabled, each request is instrumented to measure 7 discrete phases with nanosecond precision:
 
-| Phase | Description | Linux ARM64 | LLVM | WebAssembly | kVM Interp |
-| :--- | :--- | :---: | :---: | :---: | :---: |
-| **1. IPC Read (Pipe In)** | Waiting for and reading input payload from stdin | Yes | Yes | N/A (in-process) | N/A (in-process) |
-| **2. Wire Decode & Validate** | Decoding wire buffer and validating against pattern | Yes | Yes | N/A (in-process) | N/A (in-process) |
-| **3. Flat Input Prep (Arena)** | Flattening decoded structures into linear arena memory | Yes | N/A | Yes | N/A |
-| **4. Pure Evaluation** | Core relational execution loop | **Yes** | **Yes** | **Yes** | **Yes** |
-| **5. Flat Output Prep (Arena)** | Serializing/reading in-memory representations | Yes | N/A | Yes | N/A |
-| **6. Wire Encode** | Encoding result to canonical wire format | Yes | Yes | N/A (in-process) | N/A (in-process) |
-| **7. IPC Write (Pipe Out)** | Writing output wire bytes to stdout pipe | Yes | Yes | Yes (driver) | N/A |
+| Phase | Description | LLVM | WebAssembly | kVM Interp |
+| :--- | :--- | :---: | :---: | :---: |
+| **1. IPC Read (Pipe In)** | Waiting for and reading input payload from stdin | Yes | N/A (in-process) | N/A (in-process) |
+| **2. Wire Decode & Validate** | Decoding wire buffer and validating against pattern | Yes | N/A (in-process) | N/A (in-process) |
+| **3. Flat Input Prep (Arena)** | Flattening decoded structures into linear arena memory | N/A | Yes | N/A |
+| **4. Pure Evaluation** | Core relational execution loop | **Yes** | **Yes** | **Yes** |
+| **5. Flat Output Prep (Arena)** | Serializing/reading in-memory representations | N/A | Yes | N/A |
+| **6. Wire Encode** | Encoding result to canonical wire format | Yes | N/A (in-process) | N/A (in-process) |
+| **7. IPC Write (Pipe Out)** | Writing output wire bytes to stdout pipe | Yes | Yes (driver) | N/A |
 
 ### Phase Timing Output Example
 
 ```text
 --- Operation: reverse (len 40) ---
-Phase                    | Linux ARM64   | LLVM          | WebAssembly   | kVM Interp
--------------------------+---------------+---------------+---------------+---------------
-1. IPC Read (Pipe In)    |    169.83 µs  |    161.42 µs  |       -       |       -     
-2. Wire Decode & Validate |      2.04 µs  |      1.58 µs  |       -       |       -     
-3. Flat Input Prep (Arena) |      3.08 µs  |       -       |     80.88 µs  |       -     
-4. Pure Evaluation       |      0.46 µs  |      0.54 µs  |      1.71 µs  |     26.04 µs
-5. Flat Output Prep (Arena) |      2.67 µs  |       -       |     76.71 µs  |       -     
-6. Wire Encode           |      1.96 µs  |      4.88 µs  |       -       |       -     
-7. IPC Write (Pipe Out)  |     11.29 µs  |     11.08 µs  |      0.62 µs  |       -     
--------------------------+---------------+---------------+---------------+---------------
-Total Request Time       |    191.33 µs  |    179.50 µs  |    159.92 µs  |     26.04 µs
+Phase                    | LLVM          | WebAssembly   | kVM Interp
+-------------------------+---------------+---------------+---------------
+1. IPC Read (Pipe In)    |    161.42 µs  |       -       |       -     
+2. Wire Decode & Validate |      1.58 µs  |       -       |       -     
+3. Flat Input Prep (Arena) |       -       |     80.88 µs  |       -     
+4. Pure Evaluation       |      0.54 µs  |      1.71 µs  |     26.04 µs
+5. Flat Output Prep (Arena) |       -       |     76.71 µs  |       -     
+6. Wire Encode           |      4.88 µs  |       -       |       -     
+7. IPC Write (Pipe Out)  |     11.08 µs  |      0.62 µs  |       -     
+-------------------------+---------------+---------------+---------------
+Total Request Time       |    179.50 µs  |    159.92 µs  |     26.04 µs
 ```
 
 **Key Takeaways**:
-- **Pure evaluation** in Linux ARM64 native code (`0.46 µs`) is ~3.7× faster than WebAssembly (`1.71 µs`) and ~56× faster than the interpreter (`26.04 µs`).
-- **End-to-end request time** for native binaries is dominated by pipe IPC read (`~160–170 µs`).
-- **WebAssembly overhead** is concentrated in flat arena conversion (`~80 µs` in, `~76 µs` out).
+- **Pure evaluation** in LLVM native code (`0.54 µs`) is ~3.2× faster
+  than WebAssembly (`1.71 µs`) and ~48× faster than the interpreter
+  (`26.04 µs`).
+- **End-to-end request time** for native binaries is dominated by pipe
+  IPC read (`~160 µs`).
+- **WebAssembly overhead** is concentrated in flat arena conversion
+  (`~80 µs` in, `~76 µs` out).
 
 ---
 
@@ -100,22 +109,20 @@ every backend executes the exact same call path.
 
 ```text
   Function Call Profile: reverse
-  Function Name            | Linux ARM64 Calls | WebAssembly Calls | kVM Interp Calls
-  -------------------------+-------------------+-------------------+------------------
-  reverse                  |                 - |                 1 |                1
-  _reverse                 |                 - |                41 |               41
-  @dhiaXnh7AYZnewyvbXdh... |                 1 |                 - |                -
-  @EwQ2P3yZ8v4z2qA7kF...   |                41 |                 - |                -
-  car                      |                40 |                40 |               40
-  cdr                      |                40 |                40 |               40
-  cons                     |                40 |                40 |               40
-  nil                      |                 1 |                 1 |                1
-  -------------------------+-------------------+-------------------+------------------
-  Total Calls              |               163 |               163 |              163
+  Function Name            | WebAssembly Calls | kVM Interp Calls
+  -------------------------+-------------------+------------------
+  reverse                  |                 1 |                1
+  _reverse                 |                41 |               41
+  car                      |                40 |               40
+  cdr                      |                40 |               40
+  cons                     |                40 |               40
+  nil                      |                 1 |                1
+  -------------------------+-------------------+------------------
+  Total Calls              |               163 |              163
 ```
 
-*(Note: ARM64 displays canonical content hashes `@hash` for unaliased internal relations.
-All three backends arrive at the exact same total call count: 163 calls for reversing a list of length 40).*
+*(Note: Both backends arrive at the exact same total call count:
+163 calls for reversing a list of length 40).*
 
 ---
 
@@ -143,9 +150,7 @@ node scripts/perf-poly.mjs --trace
 | `TRACE_SAMPLES` | `5` | Repetitions sampled and averaged for phase timings. |
 | `TRACE` | `0` | Set to `1` (or pass `--trace`) to enable phase breakdown. |
 | `PROFILE` | `1` (with trace) | Set to `0` to disable function call counters. |
-| `ARM64_OPT` | `-O2` | Optimization level for the native ARM64 runtime (`-O0`, `-O1`, `-O2`, `-O3`). |
 | `WASM_RESET` | `1` | Reset the WebAssembly linear memory arena between calls (`1` or `0`). |
-| `ARM64_ONLY` | `0` | Run only the Linux ARM64 native target. |
 | `WASM_ONLY` | `0` | Run only the WebAssembly target. |
 | `LLVM_ONLY` | `0` | Run only the LLVM target. |
 | `BACKENDS_ONLY` | `0` | Skip the native JS baseline lanes. |
@@ -156,34 +161,17 @@ node scripts/perf-poly.mjs --trace
 # Fast smoke check with list length 10 and 1 iteration:
 ITERATIONS=1 LIST_LENGTH=10 npm run perf:poly:trace
 
-# Measure high-optimization ARM64 (-O3) vs WebAssembly on large lists (100 elements):
-LIST_LENGTH=100 ARM64_OPT=-O3 npm run perf:poly:trace
+# Trace WebAssembly on large lists (100 elements):
+LIST_LENGTH=100 WASM_ONLY=1 npm run perf:poly:trace
 
-# Isolate ARM64 native execution:
-ARM64_ONLY=1 npm run perf:poly:trace
+# Isolate LLVM native execution:
+LLVM_ONLY=1 npm run perf:poly:trace
 ```
 
 ---
 
 ## 6. Implementation Architecture
 
-### Linux ARM64 Backend
-- **Code Emission** ([`backends/arm64/src/kvm2arm64.mjs`](../backends/arm64/src/kvm2arm64.mjs)): When `options.profile` is active, each function emits counter increment instructions in its entry sequence:
-  ```asm
-      adrp  x9, k_prof_<func>
-      add   x9, x9, :lo12:k_prof_<func>
-      ldr   x10, [x9]
-      add   x10, x10, #1
-      str   x10, [x9]
-  ```
-  Counters are emitted into a dedicated `.data` section, and an exported metadata table `k_profile_entries[]` is generated.
-- **Runtime Reporting** ([`backends/arm64/src/runtime.c`](../backends/arm64/src/runtime.c)):
-  - Nanosecond phase timestamps are sampled via `clock_gettime(CLOCK_MONOTONIC, ...)` and emitted over stderr formatted as:
-    ```text
-    K_TRACE_PHASES backend=arm64 ipc_read_ns=... decode_ns=... flat_in_ns=... eval_ns=... flat_out_ns=... encode_ns=... ipc_write_ns=... total_ns=...
-    ```
-  - `dump_profile_counts()` emits nonzero function call counts between `K_PROFILE_BEGIN` and `K_PROFILE_END` tags.
-
 ### WebAssembly Backend
 - **Code Emission** ([`backends/wasm/src/kvm2wasm.mjs`](../backends/wasm/src/kvm2wasm.mjs)): Emits mutable 64-bit Wasm globals:
   ```wat

package/DOCS/REPL.md

@@ -58,7 +58,7 @@ Examples:
 ```
 
 ```k
-> bool = ?<{} true, {} false>;
+> bool? = ?<{} true, {} false>;
 ```
 
 ```k
@@ -147,7 +147,7 @@ aliases, and metadata into the session. Aliases are recovered from
 
 In `k`, there are no primitive numbers or built-in numerical literals.
 Values such as integers are represented as algebraic bit trees (e.g.
-`bits = ?< {} _, B 0, B 1 > = B;`).
+`bits? = ?< {} _, B 0, B 1 > = B;`).
 
 A codec translates between external text and enveloped *k* values:
 - `parse(text)`: parses an external string into an enveloped *k* value.
@@ -309,7 +309,7 @@ Evaluated values print in k syntax together with the inferred envelope:
 ## Example Session
 
 ```text
-> nat = ?< {} 0, N +1 > = N;
+> nat? = ?< {} 0, N +1 > = N;
 > inc = | +1;
 > {} | 0
 {}|0 ?<{} 0, ...>

package/DOCS/book/03-types-as-finite-automata.md

@@ -7,8 +7,8 @@ A schema in `k` describes a set of finite labeled trees, which can be recognized
 For example, the recursive schema of a `list`:
 
 ```k-lang
-bool = ?< {} true, {} false >;
-list = ?< {} nil, { < {} true, {} false > head, L tail } cons > = L;
+bool? = ?< {} true, {} false >;
+list? = ?< {} nil, { < {} true, {} false > head, L tail } cons > = L;
 ```
 
 corresponds to the following 4-rule grammar:
@@ -44,7 +44,7 @@ Each schema structure introduces one or more *states* in the automaton. A union
 For example, consider the `bool` schema:
 
 ```k-lang
-bool = ?< {} true, {} false >;
+bool? = ?< {} true, {} false >;
 ```
 
 This schema translates to an automaton with two states:
@@ -88,7 +88,7 @@ This traversal produces a unique and deterministic numbering for any finite dire
 For a schema representing binary natural numbers:
 
 ```k-lang
-bnat = ?< Bnat 0, Bnat 1, {} _ > = Bnat;
+bnat? = ?< Bnat 0, Bnat 1, {} _ > = Bnat;
 ```
 
 the canonical automaton form is:

package/DOCS/book/06-values-in-memory.md

@@ -111,11 +111,11 @@ Each node in the value tree is encoded based on its automaton state:
 
 #### **Example: Natural numbers**
 
-For type `bnat`, intuitively binary natural numbers defined by `bnat = ?< Bnat 0, Bnat 1, {} _ > = Bnat;`, we get
+For type `bnat?`, intuitively binary natural numbers defined by `bnat? = ?< Bnat 0, Bnat 1, {} _ > = Bnat;`, we get
 
 ```text
-> :rel bnat
-bnat = ?< Bnat 0, Bnat 1, {} _ > = Bnat;  -- @...
+> :rel bnat?
+bnat? = ?< Bnat 0, Bnat 1, {} _ > = Bnat;  -- @...
 ```
 
 The corresponding Context-Free grammar is:
@@ -191,7 +191,7 @@ Subtrees that happen to produce the same local payload bits under different type
 Consider a binary tree with repeated leaf patterns:
 
 ```k-lang
-tree = ?< { T left, T right } branch, int leaf > = T;
+tree? = ?< { T left, T right } branch, int? leaf > = T;
 ```
 
 Value: A tree corresponding to the structure:
@@ -293,8 +293,8 @@ These are encoder-side construction choices for reaching the same canonical resu
 Consider a list of similar records:
 
 ```k-lang
-record = ?{ string name, int age, string department };
-company = ?< { record head, C tail } cons, {} nil > = C;
+record? = ?{ string? name, int? age, string? department };
+company? = ?< { record? head, C tail } cons, {} nil > = C;
 ```
 
 Value representing 1000 employees where 80% work in "Engineering":
@@ -712,9 +712,9 @@ const Arena = struct {
 Consider processing a large JSON-like structure where we only need one field:
 
 ```k-lang
-metadata = ?{ timestamp created, string author };
-list = ?< { nat value, L next } cons, {} nil > = L;
-record = ?{ string name, list data, metadata meta };
+metadata? = ?{ timestamp created, string? author };
+list? = ?< { nat? value, L next } cons, {} nil > = L;
+record? = ?{ string? name, list? data, metadata? meta };
 ```
 
 For the input program `\x.x.name` (extract name field):

package/DOCS/book/08-operational-semantics-and-execution.md

@@ -153,7 +153,7 @@ for any given input, at most one result tree can be produced.
 Given:
 
 ```k-lang
-bool = ?< {} true, {} false >;
+bool? = ?< {} true, {} false >;
 neg = ?< {} true, {} false > < /true | false, /false | true >;
 ```
 

package/DOCS/book/09-compiler-architecture.md

@@ -73,8 +73,8 @@ These tables ensure that generated code can find fields and variants by number r
 Consider a simple k program:
 
 ```k-lang
-bool = ?< {} true, {} false >;
-neg = bool < /true | false, /false | true > bool;
+bool? = ?< {} true, {} false >;
+neg = bool? < /true | false, /false | true > bool?;
 ```
 
 1. **Parsing:**

package/DOCS/book/10-from-ast-to-intermediate-representation.md

@@ -42,7 +42,7 @@ Each function in the program becomes a small list or tree of such IR instruction
 Source program:
 
 ```k-lang
-bool = ?< {} true, {} false >;
+bool? = ?< {} true, {} false >;
 neg = ?< {} true, {} false > < /true | false, /false | true >;
 ```
 
@@ -50,7 +50,7 @@ The IR for `neg` can be written informally as:
 
 ```text
 neg:
-  CHECK_FILTER bool
+  CHECK_FILTER bool?
   UNION [
     SEQ [ PROJECT true, CONST false ],
     SEQ [ PROJECT false, CONST true ]

package/DOCS/book/14-canonical-serialization.md

@@ -68,7 +68,7 @@ This rule allows the decoder to know, from the type alone, how many bits to read
 For the type
 
 ```k-lang
-bnat = ?< Bnat 0, Bnat 1, {} _ > = Bnat;
+bnat? = ?< Bnat 0, Bnat 1, {} _ > = Bnat;
 ```
 
 the canonical form has three transitions from state C0.

package/Examples/arithmetics.k

@@ -3,7 +3,7 @@ swap_yes_no = < /yes |no, /no |yes >;
 yes = {}|yes;
 no = yes swap_yes_no;
 
-bits = ?< {} _, bits 0, bits 1 > = bits;
+bits? = ?< {} _, bits? 0, bits? 1 > = bits?;
 
 0b = {} | _;
 -- |1 = | 1;
@@ -64,7 +64,7 @@ GT = {inOrder /no if, () then} . then;
 EQ = {inOrder /yes if, {.x y, .y x} inOrder /yes and, () then} .then;
 
 --------------------------------------
-int = ?< <bits 0, bits 1, {} _>=bits "+", bits "-" >;
+int? = ?< <bits 0, bits 1, {} _>=bits "+", bits "-" >;
 
 remove_leading_zeros = <
   /0 remove_leading_zeros, 

package/Examples/bnat.k

@@ -1,6 +1,6 @@
 -- Standard binary encoding of natural numbers
 
-bnat = ?< {} _, bnat 0, bnat 1 > = bnat;
+bnat? = ?< {} _, bnat? 0, bnat? 1 > = bnat?;
 
 _ = {}|_;
 _1 = |1;

package/Examples/karatsuba-mult.k

@@ -5,12 +5,12 @@
 yes = {} | yes;
 no = {} | no;
 
-bits = ?< {} _, bits 0, bits 1 > = bits;
+bits? = ?< {} _, bits? 0, bits? 1 > = bits?;
 0b = {} | _;
 0 = 0b |0;
 1 = 0b |1;
 
-unat = ?< {} _, unat 1 > = unat;
+unat? = ?< {} _, unat? 1 > = unat?;
 0u = {} | _;
 
 empty = < /_ yes, no >;

package/README.md

@@ -122,9 +122,9 @@ All data structures in k are built from products and tagged unions (variants).
 Relations and pattern filters describe their domains:
 
 ```k
-bit  = ?< {} 0, {} 1 >;
-byte = ?{ Bit 0, Bit 1, Bit 2, Bit 3, Bit 4, Bit 5, Bit 6, Bit 7 };
-bits = ?< {} _, bits 0, bits 1 > = bits;
+bit?  = ?< {} 0, {} 1 >;
+byte? = ?{ Bit 0, Bit 1, Bit 2, Bit 3, Bit 4, Bit 5, Bit 6, Bit 7 };
+bits? = ?< {} _, bits? 0, bits? 1 > = bits?;
 ```
 
 There are no built-in primitive values. The empty product `{}` is the
@@ -236,7 +236,6 @@ For a detailed guide to all four formats, commands, and workflows, see
 | `k-vm` | Execute or inspect lowered kVM bytecode artifacts (`.kvm`) |
 | `k-wasm` / `k-wasm-compile` / `k-wasm-run` | Compile and run via WebAssembly backend |
 | `k-llvm-build` / `k-llvm-compile` / `k-llvm-run` | Compile and run via LLVM backend |
-| `k-arm64` / `k-arm64-compile` / `k-arm64-run` | Compile and run via Linux ARM64 native backend |
 
 Installed binary names are `k-` plus the source basename without
 `.mjs`, except for `k.mjs` itself. Source names that already include
@@ -251,9 +250,6 @@ Backends live under [`backends/`](backends/) as npm workspaces:
   and the standalone Web REPL.
 - [`backends/llvm`](backends/llvm/) lowers polymorphic kVM programs into
   LLVM IR and compiled native test executables.
-- [`backends/arm64`](backends/arm64/) lowers polymorphic kVM programs
-  directly into standalone Linux ARM64 native executables without external
-  compiler dependencies.
 
 All backends integrate with the compiler and binary codecs through
 [`backend-api.mjs`](backend-api.mjs).
@@ -353,7 +349,6 @@ npm run prepare         # regenerate parsers from .jison grammars
 npm test                # run the fail-fast full suite with per-test timings
 npm run test:wasm       # run the WebAssembly backend tests
 npm run test:llvm       # run the LLVM backend tests
-npm run test:arm64      # run the Linux ARM64 backend tests
 npm run build:repl-html # build the standalone single-file Web REPL (repl.html)
 npm run compare         # run multi-backend benchmark and conformance harness
 npm run perf:poly       # run polymorphic benchmark across backends

package/backend-api.mjs

@@ -4,7 +4,15 @@ export { decodeWire, encodeToWire } from "./codecs/runtime/prefix-codec.mjs";
 export { exportPatternGraph, NODE_KIND } from "./codecs/runtime/codec.mjs";
 export { patternToPropertyList, propertyListToPattern } from "./codecs/runtime/pattern-json.mjs";
 export { Value, fromObject, isProduct, isVariant, isValue } from "./Value.mjs";
-export { KIR_FORMAT, KIR_VERSION, objectToKIRP, retypeObjectRelation, retypeObjectRelationForBackend } from "./kir.mjs";
+export {
+  KIR_FORMAT,
+  KIR_VERSION,
+  objectToKIRP,
+  relationPatternPropertyList,
+  retypeObjectRelation,
+  retypeObjectRelationForBackend,
+  specializeObjectRelations
+} from "./kir.mjs";
 export { compileLibrary, decodeObject, loadLibrary } from "./object.mjs";
 export { createState, evaluateInput } from "./repl.mjs";
 export { parse as parseFloat64, print as printFloat64 } from "./codecs/ieee.mjs";