@fraczak/k 7.1.0 → 8.0.0

package/DOCS/NAMED_PATTERNS.md

@@ -0,0 +1,317 @@
+# Named Patterns and Parameterized Type Schemes in k
+
+## 1. Overview and Motivation
+
+Following commit `a4eec258`, type code expressions (`$ code`) were
+removed in favor of pure filter relations (`? <...> = Self;`).
+While this eliminated the redundant dual syntax of static codes versus
+runtime filters, practical development (notably in `djson` variants and
+standard libraries) revealed a major drawback: **loss of pattern
+composition and reuse**.
+
+Without named, reusable patterns:
+- Monolithic structures (such as UTF-8 decoding and IEEE-754 bit
+  partitions) had to be copy-pasted inline across dozens of files.
+- Common algebraic shapes like linked lists, pairs, dictionaries, and
+  tries could not be defined generically; each variant had to inline
+  its own structural definition.
+- Filter relations (`rel?(x)`) perform runtime filtering but cannot be
+  used directly as structural type shapes inside other pattern
+  definitions.
+
+This document establishes the specification for **Named Patterns**:
+parameterized, compositional regular tree grammar templates that re-enable
+reusable type definitions with zero syntax bloat, guaranteed
+termination, and full integration with k's graph-based type system.
+
+---
+
+## 2. The Core Model: Patterns as Open Directed Graphs
+
+In k, all values, patterns, and type codes are directed graphs
+representing regular tree languages. A named pattern definition:
+
+```k
+name[ P1, P2, ... Pn ] = pattern_graph;
+```
+
+defines an **open directed graph** with an explicit boundary interface.
+
+### 2.1 The Three Classes of Variables
+
+Within a pattern definition, every variable identifier falls into one
+of three orthogonal categories:
+
+1. **External Ports ($\forall$ / Parameters)**:
+   Any variable listed in the header brackets `[ P1, ... Pn ]` is an
+   **external port**. These represent open inputs to be supplied by the
+   caller upon instantiation.
+
+2. **Internal Variables ($\exists$ / Unification Nodes)**:
+   Any variable appearing on the right-hand side that is **not** listed
+   in `[ P1, ... Pn ]` is an **internal variable**.
+   - If an internal variable appears in multiple locations, it asserts
+     **structural type equality (unification)** between those sites.
+   - Internal variables are existentially quantified ($\exists$) and
+     scoped strictly to the pattern definition.
+
+3. **Cycle Knots ($\mu$ / Fixpoints)**:
+   Any variable bound via `= KnotName` is an internal recursive knot.
+   It creates a back-edge in the directed graph, closing a loop.
+   Its scope is purely local: callers cannot see or reference it.
+
+### 2.2 Knot and Variable Hiding ($\alpha$-Equivalence)
+
+In:
+
+```k
+list[X] = < {}nil, { X car, Y cdr } cons > = Y;
+```
+
+- `X` is listed in `list[X]` $\implies$ **External Port**.
+- `Y` is bound by `= Y` and omitted from `list[X]` $\implies$
+  **Internal Knot**.
+
+`Y` is strictly encapsulated. It can be $\alpha$-renamed to any
+internal node ID (`#knot_0`) without changing the pattern's external
+interface or behavior. Callers only interact with the port `X`.
+
+---
+
+## 3. The Four-Bracket Symmetry of k
+
+Named patterns introduce square brackets `[...]` into k's grammar.
+This completes an orthogonal four-bracket architecture where each
+bracket style has a dedicated, non-overlapping semantic domain:
+
+| Bracket Pair | Semantic Domain | Concrete Purpose |
+| :--- | :--- | :--- |
+| **`{ ... }`** | **Products** | Records, tuples, structs |
+| **`< ... >`** | **Unions** | Variants, sums, choices |
+| **`( ... )`** | **Relations** | Composition, grouping, identity |
+| **`[ ... ]`** | **Patterns** | Type templates, instantiations |
+
+No dollar prefix (`$`) is needed anywhere in the language.
+
+### 3.1 Unambiguous Lexical Distinction
+
+Because all pattern references carry `[...]`, the lexical distinction
+between variables and patterns is 100% deterministic:
+
+- **Identifier without `[...]`** (`X`, `T`, `car`, `Y`):
+  - In label position: field or variant tag (`car`, `cdr`, `nil`).
+  - In pattern position: variable node (`X`, `T`, knot `Y`).
+- **Identifier with `[...]`** (`bit[]`, `list[T]`, `pair[A, B]`):
+  - Always a pattern template lookup or instantiation.
+
+---
+
+## 4. Internal Variables as Unification Knots
+
+A critical insight of k's graph-based model is that unparameterized
+patterns can contain internal variables to express equality
+constraints across fields:
+
+```k
+byte[] = { bit 0, bit 1, ... };
+```
+
+Here:
+- `bit` does not have `[]`, so it is a **variable**, not a pattern.
+- `bit` is not in the parameter list `byte[]`, so it is an **internal
+  node**.
+- Because `bit` appears at both field `0` and field `1`, it asserts
+  that **field `0` and field `1` must share the exact same type**,
+  without constraining what that type must be.
+
+### 4.1 Comparison of Pattern Declarations
+
+```k
+-- 1. Homogeneous pair of two fields of the SAME arbitrary type:
+same_pair[] = { T first, T second };
+
+-- 2. Heterogeneous pair parameterized by the caller:
+pair[A, B] = { A first, B second };
+
+-- 3. Pair of concrete bits:
+bit_pair[] = { bit[] first, bit[] second };
+
+-- 4. Instantiation enforcing equality via shared variable:
+diagonal_pair[] = pair[T, T];
+```
+
+In `diagonal_pair[] = pair[T, T]`:
+- `T` is an internal variable.
+- Instantiating `pair` with `T` for both arguments unifies both ports,
+  producing a closed pattern requiring equal elements.
+
+---
+
+## 5. Instantiation Semantics (Option B)
+
+Arguments inside `[...]` may be either **variables** or **patterns**:
+
+1. **Passing a Variable (`T`, `X`)**:
+   Connects the template's input port directly to that existing node in
+   the pattern graph, enabling node sharing, unification, and
+   polymorphic relations.
+
+2. **Passing an Inline Pattern (`int[]`, `pair[K, V]`, `<{}0, {}1>`)**:
+   Creates an anonymous node representing the pattern and connects the
+   input port to it.
+
+### 5.1 Equivalence to Variable Binding
+
+Passing an inline pattern `P` is semantically equivalent to introducing
+a fresh internal node variable:
+
+$$name[P] \;\;\Longleftrightarrow\;\; (P = \_anon) \; name[\_anon]$$
+
+Both forms construct isomorphic graph structures that minimize to the
+exact same canonical DFA representation in `codes.mjs`.
+
+### 5.2 Single-Step Finite Graph Substitution
+
+Because recursive cycles are closed internally via knots (`= Y`),
+instantiating a template does **not** require recursive unrolling or
+fixpoint searching.
+
+Instantiation is a single-step graph substitution:
+1. Copy the template's graph structure (fresh private IDs for internal
+   knots).
+2. Substitute the caller's arguments into the designated open port nodes.
+3. Minimize via Hopcroft/Moore DFA partition refinement in `codes.mjs`.
+
+---
+
+## 6. Safety Invariants and Termination
+
+To guarantee decidability and termination:
+
+1. **Acyclic Template Dependency Rule**:
+   A pattern template `$ name[...]` cannot reference `name` in its own
+   definition.
+   - All recursion **must** be expressed through internal knots (`= Y`).
+   - Consequently, the template dependency graph is a Strictly Acyclic
+     Directed Graph (DAG).
+   - Non-regular polymorphic recursion (nested datatypes) is structurally
+     impossible, guaranteeing that every instantiated pattern is a
+     finite regular tree automaton.
+
+2. **Lexical Scope Independence**:
+   Internal variable names and knot names are strictly private to each
+   definition. Two patterns may both use knot name `Y` or variable `T`
+   without collision.
+
+3. **Canonical Confluence**:
+   In k, type codes are structural, not nominal. Any two instantiations
+   that yield isomorphic regular tree automata produce identical
+   canonical hashes and wire encoders.
+
+---
+
+## 7. Concrete Library Examples
+
+### 7.1 Core Data Types
+
+```k
+-- Canonical bit and bit-path numbers:
+bit[]  = < {}0, {}1 >;
+bits[] = < {} _, B 0, B 1 > = B;
+
+-- Byte as an 8-bit octet product:
+byte[] = {
+  bit[] 0, bit[] 1, bit[] 2, bit[] 3,
+  bit[] 4, bit[] 5, bit[] 6, bit[] 7
+};
+
+-- 7-bit ASCII code points:
+ascii[] = {
+  bit[] 6, bit[] 5, bit[] 4, bit[] 3,
+  bit[] 2, bit[] 1, bit[] 0
+};
+```
+
+### 7.2 Generic Data Structures
+
+```k
+-- Generic pair:
+pair[A, B] = { A fst, B snd };
+
+-- Generic singly-linked list:
+list[X] = < {}nil, { X car, Y cdr } cons > = Y;
+
+-- Generic dictionary:
+dict[K, V] = list[pair[K, V]];
+
+-- Generic binary tree with internal knot T:
+tree[X] = < {}nil, { X val, T left, T right } node > = T;
+```
+
+### 7.3 Usage in Relations
+
+```k
+-- Type guard filter:
+int? = ? int[];
+
+-- Polymorphic list destructuring with type unification:
+head = ? { X car, list[X] cdr } X;
+
+-- Concrete typed list destructuring:
+sum = ? { int[] = T car, list[T] cdr } ...;
+
+-- Anonymous pattern matching:
+validate_ints = ? list[int[]];
+```
+
+---
+
+## 8. Summary of Grammar Extensions
+
+### 8.1 Lexer Tokens
+
+```
+"["   return 'LB';
+"]"   return 'RB';
+```
+
+### 8.2 Top-Level Definitions
+
+```
+defs
+    : /* empty */
+    | defs name eq comp sc
+    | defs name lb pattern_params rb eq filter sc
+    ;
+
+pattern_params
+    : /* empty */
+    | non_empty_pattern_params
+    ;
+
+non_empty_pattern_params
+    : name
+    | non_empty_pattern_params comma name
+    ;
+```
+
+### 8.3 Pattern References and Instantiations
+
+```
+filter_
+    : lp dots rp
+    | la labelled_filters ra
+    | lc labelled_filters rc
+    | name lb pattern_args rb
+    ;
+
+pattern_args
+    : /* empty */
+    | non_empty_pattern_args
+    ;
+
+non_empty_pattern_args
+    : filter
+    | non_empty_pattern_args comma filter
+    ;
+```

package/DOCS/PATTERNS.md

@@ -1,13 +1,14 @@
 # Schemas and Pattern Graphs
 
-In `k`, an algebraic **schema** describes the shape of payload trees that may flow
-through a relation. In compiler artifacts and serialization, schemas are represented
-as property-list arrays of automata nodes. Schemas are used by:
+In `k`, an algebraic **schema** describes the shape of payload trees
+that may flow through a relation. In compiler artifacts and
+serialization, schemas are represented as property-list arrays of
+automata nodes. Schemas are used by:
 
 - the contract-derivation engine
 - the binary codec
 - runtime framed values `(schema, payload)`
-- filter expressions (`?schema`)
+- filter expressions (`?schema` or `?name[...]`)
 
 ## Pattern Kinds
 
@@ -46,26 +47,68 @@ Example:
 
 This is not the wire format. It is the canonical readable export form.
 
-## Filters and Type Names
+## Named Patterns and Templates
+
+Named patterns define reusable, modular regular tree grammars using
+square brackets `[...]`:
+
+```k
+name[ P1, P2, ... Pn ] = filter;
+```
+
+For 0-arity patterns (no parameters), empty brackets `[]` are used:
+
+```k
+bit[]  = < {} 0, {} 1 >;
+bits[] = < {} _, B 0, B 1 > = B;
+byte[] = {
+  bit[] 0, bit[] 1, bit[] 2, bit[] 3,
+  bit[] 4, bit[] 5, bit[] 6, bit[] 7
+};
+```
+
+Parameterized patterns declare external ports in the bracket list:
+
+```k
+list[X] = < {} nil, { X car, Y cdr } cons > = Y;
+pair[A, B] = { A first, B second };
+```
+
+Callers instantiate a named pattern:
+- As a standalone filter: `? list[X]` or `? bits[]`
+- Within relation guards: `?{ nat[] = N x, ... }`
+- As template arguments: `list[byte[]]` or `pair[A, B]`
+
+Inside a definition, knot identifiers (`= Y`) close internal recursive
+loops. Recursive loops are private and alpha-renamed during expansion.
+Direct or mutual recursion among templates (`bits[]` calling `bits[]`)
+is disallowed to ensure every template dependency graph is an acyclic
+DAG, guaranteeing finite regular tree automaton compilation.
+
+## Filters and Terminal Positions
 
 A k script can describe a pattern through:
 
 - a relation in terminal position
 - a filter expression in terminal position
+- a named pattern invocation (`? name[...]`)
 
 Examples:
 
 ```k
-bits? = ?< {} _, bits? 0, bits? 1 > = bits?;
-list? = ?< {} nil, { < {} _, B 0, B 1 >=B car, L cdr } cons > = L;
+bits[] = < {} _, B 0, B 1 > = B;
+list[X] = < {} nil, { X car, Y cdr } cons > = Y;
+list? = ? list[bits[]];
 list?
 ```
 
+Or anonymously:
+
 ```k
-?< {} nil, { < {} _, B 0, B 1 >=B car, X cdr } cons > = X
+? list[bits[]]
 ```
 
-In both cases, the compiler derives a root pattern from `__main__`.
+In all cases, the compiler derives a root pattern from `__main__`.
 
 ## Pattern Export Helper
 
@@ -86,13 +129,18 @@ It:
 Example:
 
 ```bash
-echo '?< {} nil, { < {} _, B 0, B 1 >=B car, X cdr } cons > = X' | node ./patterns/from-k.mjs
+echo '?< {} nil, { {} car, X cdr } cons > = X' | \
+  node ./patterns/from-k.mjs
 ```
 
 Typical output:
 
 ```json
-[["closed-union",[["nil",1],["cons",2]]],["closed-product",[]],["closed-product",[["car",3],["cdr",0]]],["closed-union",[["_",1],["0",3],["1",3]]]]
+[
+  ["closed-union", [["nil", 1], ["cons", 2]]],
+  ["closed-product", []],
+  ["closed-product", [["car", 1], ["cdr", 0]]]
+]
 ```
 
 ## Schemas in the Codec

package/DOCS/REPL.md

@@ -33,10 +33,13 @@ is complete.
 | Command | Meaning |
 | --- | --- |
 | `:help` | Show command summary |
-| `:engine [wasm|js]` | Display or switch evaluation engine (`wasm` or `js`) |
-| `:wasm` / `:js` | Shortcut to switch engine |
+| `:engine [wasm\|pkir\|js]` | Display or switch evaluation engine (`wasm`, `pkir`, or `js`) |
+| `:wasm` / `:pkir` / `:js` | Shortcut to switch engine |
 | `:rel name` | Show relation definition |
 | `:rels` | List relation aliases |
+| `:pattern name` | Show named pattern definition (alias: `:pat`) |
+| `:patterns` | List defined named pattern templates (alias: `:pats`) |
+| `:limit [num\|none]` | Set maximum characters for value output (default: 4096) |
 | `:codec load file` | Load a codec from an ES module file (e.g. `:codec load codecs/int.mjs`) |
 | `:codec unload name` | Unload a registered codec |
 | `:codec list` | List loaded REPL codecs (alias: `:codecs`) |
@@ -50,6 +53,8 @@ is complete.
 ## Raw Snippets
 
 Raw input is compiled as k source on top of the current state.
+Both relation definitions (`name = expr;`) and named pattern templates
+(`name[...] = filter;`) can be introduced incrementally.
 
 Examples:
 
@@ -58,11 +63,17 @@ Examples:
 ```
 
 ```k
-> bool? = ?<{} true, {} false>;
+> bool[] = < {} true, {} false >;
+> bool? = ? bool[];
 ```
 
 ```k
-> not = ?<{} true, {} false> < /true | false, /false | true >;
+> list[X] = < {} nil, { X car, Y cdr } cons > = Y;
+> ? list[bool[]]
+```
+
+```k
+> not = ? bool[] < /true | false, /false | true >;
   {} |true not
 ```
 
@@ -92,6 +103,7 @@ The interpreter keeps:
 
 - `rels`: canonical compiled relations
 - `relAliases`: human relation names to canonical hashes
+- `patterns`: defined named pattern templates
 - `value`: current value, initially `{}`
 
 Definitions are content-addressed. Rebinding an alias changes the
@@ -231,11 +243,13 @@ The REPL supports two evaluation engines:
 
 ### CLI Options
 
-When starting `k-repl`, choose the engine with:
+When starting `k-repl`, choose the engine or output limit with:
 
 ```bash
 k-repl --engine=js    # or k-repl --js
+k-repl --engine=pkir  # or k-repl --pkir
 k-repl --engine=wasm  # or k-repl --wasm (default)
+k-repl --limit=8192   # set max characters for rendered output
 ```
 
 ## Timing and Profiling
@@ -297,6 +311,11 @@ Evaluated values print in k syntax together with the inferred envelope:
 {}|0|+1 ?<<{} 0, ...> +1, ...>
 ```
 
+Large values are rendered iteratively and truncated at `maxChars`
+(default: `4096` characters) so deeply nested or large values print
+instantly without exhausting stack or terminal buffers. Use
+`:limit <num>` or `:limit none` to adjust or disable the limit.
+
 `undefined` prints as:
 
 ```text

package/DOCS/WEB_REPL_REQUIREMENTS.md

@@ -112,8 +112,10 @@ The bundled VFS and UI examples must include only verified useful files:
 
 #### 1. Curated Files Explorer
 In the Web REPL "Files" (VFS) explorer, the visible files are strictly curated to verified examples and codecs:
-- **k-codes**: `core.k`, `arithmetics.k`, `ieee.k`
-- **codecs**: `json.mjs`, `utf8.mjs`, `int.mjs`, `unit.mjs`, `ieee.mjs`
+- **k-codes**: `core.k`, `arithmetics.k`, `ieee.k`, `djson.k`,
+  `djson-btrie.k`, `djson-ptrie.k`
+- **codecs**: `json.mjs`, `djson.mjs`, `djson-btrie.mjs`,
+  `djson-ptrie.mjs`, `utf8.mjs`, `int.mjs`, `unit.mjs`, `ieee.mjs`
 - User-created or uploaded files remain visible.
 - Internal runtime artifacts (`backends/wasm/runtime.wat`) and redundant directory prefixes (`Examples/`, `codecs/`) are kept accessible internally but hidden from the default file listing.
 - Clicking "Load" on a `.mjs` file automatically executes `:codec load <filename>`.

package/Examples/arithmetics.k

@@ -3,7 +3,8 @@ swap_yes_no = < /yes |no, /no |yes >;
 yes = {}|yes;
 no = yes swap_yes_no;
 
-bits? = ?< {} _, bits? 0, bits? 1 > = bits?;
+bits[] = < {} _, B 0, B 1 > = B;
+bits? = ? bits[];
 
 0b = {} | _;
 -- |1 = | 1;
@@ -28,7 +29,7 @@ empty = < /_ yes, no >;
 empty? = {empty /yes if, () then} .then;
 
 concat = {.x inv x, .y y} concat_; 
-concat_ = ?{ <X 0, X 1, {} _>=X x, ... }
+concat_ = ?{ bits[] = X x, ... }
   < 
     {.x empty? if, .y then} .then,
     < 
@@ -37,7 +38,7 @@ concat_ = ?{ <X 0, X 1, {} _>=X x, ... }
     > concat_ 
   >;
 inv = {()x, 0b r} _inv; 
-_inv = ?{ <X 0, X 1, {} _>=X x, ... }
+_inv = ?{ bits[] = X x, ... }
   < 
     {.x empty? if, .r then} .then,
     < 
@@ -47,7 +48,7 @@ _inv = ?{ <X 0, X 1, {} _>=X x, ... }
   >;
 
 inOrder = {.x inv x, .y inv y, yes inOrder} inOrder_;
-inOrder_ = ?{ <X 0, X 1, {} _>=X x, ... }
+inOrder_ = ?{ bits[] = X x, ... }
   < 
     {.x </0,/1> if1, .y /_ if2, .inOrder swap_yes_no then} .then,
     {.x /_ if, .inOrder then} .then,
@@ -64,7 +65,8 @@ 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[] "+", bits[] "-" >;
+int? = ? int[];
 
 remove_leading_zeros = <
   /0 remove_leading_zeros, 
@@ -85,7 +87,7 @@ inc = <
   /'-' {inv x, 0b y} _dec nat |'-'
 >;
 
-_inc = ?{ <X 0, X 1, {} _>=X x, ... } <
+_inc = ?{ bits[] = X x, ... } <
     {.x empty? if, .y |1 then} .then,
     {.x /0 x, .y |1 y} concat_, 
     {.x /1 x, .y |0  y} _inc
@@ -97,7 +99,7 @@ dec = <
   /'-' {inv x, 0b y} _inc nat |'-'
 >;
 
-_dec = ?{ <X 0, X 1, {} _>=X x, ... } <
+_dec = ?{ bits[] = X x, ... } <
     {.x /1 x, .y |0  y} concat_, 
     {.x /0 x, .y |1 y} _dec
 >;
@@ -128,7 +130,7 @@ _plus = {.x x, .y y, .c c, 0b r} _plus_;
 
 _plus_ =
   -- least significant bit first addition with carry
-  ?{ <X 0, X 1, {} _>=X x, ... }
+  ?{ bits[] = X x, ... }
   <
     {.x empty? if, .y empty? and, .c/0 c, .r inv then} .then,
     {.x empty? if, .y empty? and, {.r x, 1 r} _inv then} .then,
@@ -156,7 +158,7 @@ _minus = {.x x, .y y, .c c, 0b r} _minus_;
 
 _minus_ =
   -- least significant bit first substraction with carry
-  ?{ <X 0, X 1, {} _>=X x, ... }
+  ?{ bits[] = X x, ... }
   <
     {.y empty? if, .c/0 and, {.r x, .x r} _inv then} .then,
     <
@@ -199,7 +201,7 @@ times =
 ;
 
 _times =
-  ?{ <Y 0, Y 1, {} _>=Y y, ... }
+  ?{ bits[] = Y y, ... }
   <
     { .y empty? if, .result then } .then,
     <
@@ -226,7 +228,7 @@ shift_in_1 = inv |1 inv nat;
 sub_bits = {.x inv x, .y inv y, c0 c} _minus inv nat;
 
 _div_restoring =
-  ?{ <X 0, X 1, {} _>=X x, ... }
+  ?{ bits[] = X x, ... }
   <
     {.x empty? if, {.q inv int div, .r rem} then} .then,
     <
@@ -241,13 +243,16 @@ _div_restoring =
       {.y x, .r y} inOrder test
     }
     <
-      {.test /yes if, {.x x, .y y, .q |1 q, {.r x, .y y} sub_bits r} then} .then,
+      {
+        .test /yes if,
+        {.x x, .y y, .q |1 q, {.r x, .y y} sub_bits r} then
+      } .then,
       {.test /no  if, {.x x, .y y, .q |0 q, .r r} then} .then
     >
     _div_restoring
   >;
 
-_pad_down = ?{ <X 0, X 1, {} _>=X x, <S 0, S 1, {} _>=S steps, ... }
+_pad_down = ?{ bits[] = X x, bits[] = S steps, ... }
   <
     {.x empty? if, {._y _y, .steps steps} then} .then,
     {
@@ -257,7 +262,7 @@ _pad_down = ?{ <X 0, X 1, {} _>=X x, <S 0, S 1, {} _>=S steps, ... }
     } _pad_down
   >;
 
-_align_down = ?{ <X 0, X 1, {} _>=X x, <Y 0, Y 1, {} _>=Y y, ... }
+_align_down = ?{ bits[] = X x, bits[] = Y y, ... }
   <
     {
       .x </0, /1> x,
@@ -277,7 +282,7 @@ _align_down = ?{ <X 0, X 1, {} _>=X x, <Y 0, Y 1, {} _>=Y y, ... }
     } .then
   >;
 
-_div_down = ?{ <X 0, X 1, {} _>=X steps, ... }
+_div_down = ?{ bits[] = X steps, ... }
   {
     .x x,
     ._y _y,
@@ -321,7 +326,7 @@ _div_down = ?{ <X 0, X 1, {} _>=X steps, ... }
     } _div_down
   >;
 
-_check_2y = ?{ <X 0, X 1, {} _>=X x, <Y 0, Y 1, {} _>=Y y, ... }
+_check_2y = ?{ bits[] = X x, bits[] = Y y, ... }
   <
     {.x empty? if, {} | down_shift then} .then,
     {.y empty? if, {} | restore then} .then,
@@ -393,7 +398,7 @@ gcd =
   > _gcd
 ;
 
-_gcd = ?{ <X 0, X 1, {} _>=X x, ... } <
+_gcd = ?{ bits[] = X x, ... } <
   { .y remove_leading_zeros empty? if, .x nat then } .then,
   { .y x, mod y } _gcd
 >;