@fraczak/k 6.1.2 → 6.1.3

package/DOCS/BIG_PICTURE.md

@@ -12,7 +12,7 @@ with that tree.
 
 ### Types (codes)
 
-Formally, a _type_ is a (subclass of finite tree automata. The type defines a set of its values,
+Formally, a _type_ is a finite tree automaton. The type defines a set of values,
 which corresponds to the set of trees accepted by the automaton.
 Therefore, every type admits a unique normal form in terms of its minimal deterministic tree automaton.
 
@@ -38,7 +38,7 @@ Given a finite (possibly empty) set of types `t1, t2, ..., tn` and a set of pair
   Each projection function maps a value of type `{t1 l1, t2 l2, ..., tn ln}`
   into a value of type `t1`, `t2`, `...`, `tn`, respectively.
 - by `< t1 l1, t2 l2, ..., tn ln >`, we define a _union type_ with exactly `n` projection functions `/l1`, `/l2`, `...`, `/ln`,
-  maps a value of type `<t1 l1, t2 l2, ..., tn ln>` into a value of type `t1`, `t2`, `...`, `tn`, respectively.
+  mapping a value of type `<t1 l1, t2 l2, ..., tn ln>` into a value of type `t1`, `t2`, `...`, `tn`, respectively.
 
 Intuitively, the projection functions on a product type are all total (meaning, they are defined for every value of the
 input product type), whereas in the case of a union type, exactly one projection function is defined
@@ -68,7 +68,7 @@ Two (possibly recursive) codes are equivalent iff they are bisimilar over their
 
 ### Filters (patterns)
 
-A _filter_ is a way of representing a _pattern_, i.e, a set of types sharing some structure.
+A _filter_ is a way of representing a _pattern_, i.e., a set of types sharing some structure.
 For example, if I wanted to refer to all product types that have a field `f` of type `T`,
 I would write: `?{ T f, ... }`. In general, a filter is defined by:
 
@@ -158,14 +158,14 @@ registry of types (schemas) and functions.
 
 ## Typing and Polymorphism (codes and patterns)
 
-Abstract Syntax Tree of a program consists of a dictionary of _type definitions_,
-a dictionary  of _function definitions_, and the final _main expression_.
+The abstract syntax tree of a program consists of a dictionary of _type definitions_,
+a dictionary of _function definitions_, and the final _main expression_.
 
 In principle, the initial form of the Abstract Syntax Tree, _raw_ AST, is enough to evaluate
 the program on an input.
 
-Our objective however is to compute canonical representations for types and normalized
-representations for functions, so they could be reused.
+Our objective, however, is to compute canonical representations for types and normalized
+representations for functions so they can be reused.
 
 The normalization steps are:
 
@@ -225,7 +225,7 @@ Functions `inc` and `inc3` are (non-polymorphic) functions of types
 `${ bit overflown, byte byte } -> ${ bit overflown, byte byte }`, respectively.
 
 Function `inc_o` is a polymorphic function of type patterns: `?X -> ${ byte byte, bit overflown }`
-with following constraints:
+with the following constraints:
 
 - `?X` is a product type with at least two fields: `byte` and `overflown`, denoted by:
    > `?{ $byte byte, Z overflown, ...}`;
@@ -269,7 +269,7 @@ The registry will be a key-value store, where the key is the hash of the normali
 and the value is the normalized type itself.
 
 All functions (non-polymorphic and polymorphic) will be renamed by the hash of their normalized
-definition and stored in the similar key-value store.
+definition and stored in a similar key-value store.
 
 Non-polymorphic functions can be easily indexed by the hashes of their input and output types
 so that we can quickly find the function we need.
@@ -280,7 +280,7 @@ Indexing polymorphic functions seems complicated (TODO).
 The language is designed to transform _codes_, i.e., serialized typed values, i.e., trees
 accepted by a tree automaton, into other _codes_.
 The transformation is done by partial functions as defined in the language.
-The non-recursive and tail-recursive (and even some non-tail recursive) functions can
+The non-recursive and tail-recursive (and even some non-tail-recursive) functions can
 be compiled into deterministic finite (pushdown) transducers.
 
 ### AND-OR graphs for encoding and decoding codes

package/DOCS/DIVERGENCE_DETECTION.md

@@ -19,6 +19,6 @@ HEAD(?F E) = HEAD(E)
 HEAD($T E) = HEAD(E)
 HEAD((E1 E2 ...)) = HEAD(E1)
 HEAD({ E1 f1, E2 f2, ... }) = HEAD(E1) union HEAD(E2) union ...
-HEAD(<E1, E2, ...>) = {}   -- heads of a union is empty set
+HEAD(<E1, E2, ...>) = {}   -- the head of a union is the empty set
 HEAD(/ tag) = HEAD(. lab) = HEAD(| tag) = {}
 ```

package/DOCS/TYPE_DERIVATION.md

@@ -4,7 +4,7 @@
 
 This algorithm infers type constraints for programs consisting of mutually recursive partial functions over algebraic data types (products and unions).
 
-**Input:** AST of a `k` program, consisting of function definitions (expressions) - can be seen as a set of (recursive) equations.
+**Input:** AST of a `k` program, consisting of function definitions (expressions), which can be seen as a set of recursive equations.
 **Output:** Annotated AST with type patterns (also called filters)
 
 It is assumed that we have access (through APIs) to a universal "type registry", which provides us with unique (canonical) names for each type.
@@ -22,12 +22,12 @@ A **pattern** represents a set of types:
 | `<>` | Closed union | Exactly specified |
 | `T` | Named type | From type definition |
 
-**Fields:** Each pattern has associated field labels. For open patterns, additional fields may exist. For closed patterns, the field set is exact. 
+**Fields:** Each pattern has associated field labels. For open patterns, additional fields may exist. For closed patterns, the field set is exact.
 Unknown-kind patterns have only the open form `(...)`; a closed filter must choose product `{...}`/`{}` or union `<...>`/`<>`.
 
 A type pattern is a singleton pattern, i.e., only one type is captured by such a pattern.
 
-## 3. Pattern Graph - a data structure used during type derivation
+## 3. Pattern Graph - A Data Structure Used During Type Derivation
 
 **Nodes:** Patterns organized in a "reps" (representatives) forest, similar to union-find. However, a union of two (or more) different trees always produces a new "rep" (root) node, joining the trees.
 **Edges:** Labeled by field names, pointing to other patterns
@@ -42,13 +42,13 @@ A type pattern is a singleton pattern, i.e., only one type is captured by such a
 
 ## 4. Unification
 
-`unify(p₁, ..., pₙ)` computes the least upper bound (most specific common pattern); it may add a new node (rep) into the reps forest; the operation does not modify any existing pattern node
+`unify(p₁, ..., pₙ)` computes the least upper bound (most specific common pattern); it may add a new node (rep) into the reps forest, but it does not modify any existing pattern node.
 
 **Rules:**
 
 - **Open + Open:** Merge field sets, stay open
-- **Open + Closed:** Check fields ⊆, become closed
-- **Closed + Closed:** Check fields =, stay closed
+- **Open + Closed:** Check field inclusion, then become closed
+- **Closed + Closed:** Check field equality, then stay closed
 - **Product ⊥ Union:** Error (incompatible)
 - **Type T:** Unique (canonical name)
 
@@ -75,7 +75,7 @@ out(eᵢ) = in(eᵢ₊₁)  for i = 1..n-1
 out((e₁ e₂ ... eₙ)) = out(eₙ)
 ```
 
-In case when `n=0`, identity, `()`
+When `n=0`, the composition is the identity, `()`.
 
 ```text
 in(()) = out(())
@@ -136,7 +136,7 @@ in(T) = out(T) = pattern(T)
 see patterns.filterToPattern(F)
 ```
 
-Filter expression is a syntax for describing pattern graphs.
+A filter expression is syntax for describing pattern graphs.
 
 ## 6. Global Algorithm
 
@@ -166,13 +166,13 @@ For each SCC (in topological order):
     For each function `f` in SCC:
       1. Compact `f`'s pattern graph
       2. For each occurrence `o` of `g` in `f`, clone(in(g), out(g)) and unify input and output patterns of `o` with the corresponding cloned patterns
-      
+
     If pattern graphs unchanged: break
 ```
 
 ## 7. Compaction
 
-**Purpose:** Replace all pattern nodes by their reps and replace all singleton patterns by types.
+**Purpose:** Replace all pattern nodes with their reps and replace all singleton patterns with types.
 
 **Algorithm:**
 
@@ -186,7 +186,7 @@ For each SCC (in topological order):
 
 **Criterion:** Pattern graph structure unchanged between iterations
 
-**Measured by:** 
+**Measured by:**
 1. Representative forest structure (parent pointers)
 2. Edge sets for each representative
 3. Pattern descriptors for each representative
@@ -206,7 +206,7 @@ Converged = (current_state == previous_state)
 
 ## 9. Error Handling
 
-**Unification errors:**
+**Unification errors include:**
 
 - Product vs Union
 - Closed pattern field mismatch

package/DOCS/book/01-introduction.md

@@ -44,8 +44,8 @@ computation in a concise and understandable way.
 
 There is another concept in the language, called **filters**.
 Filters play a role in the process of reasoning about types of partial functions.
-Filters have been added to the syntax of the language as they allow explicit annotations
-of "polymorphic" expressions, i.e., expressions which make sense in different contexts.
+Filters have been added to the syntax of the language because they allow explicit annotations
+of "polymorphic" expressions, i.e., expressions that make sense in different contexts.
 Filters are similar to *type classes* in other languages.
 
 ---

package/DOCS/book/02-syntax-and-values.md

@@ -10,7 +10,7 @@ $ type_name = ...type_expression... ;
 function_name = ...expression... ;
 ```
 
-The definitions are followed in the file by the *main expression*; it represents the partial function defined by the program as a whole.
+The definitions are followed in the file by the *main expression*, which represents the partial function defined by the program as a whole.
 
 There is no syntax for values.
 Every syntactic form in an expression describes a **function** -- possibly a constant function that always returns the same value.
@@ -48,22 +48,22 @@ Every type denotes a finite tree automaton whose accepted trees are the possible
 
 ## **2.4 Projections**
 
-**Dot** notation, e.g., 
+**Dot** notation, e.g.,
 
 ```k
  . field_name
 ```
 
 is used for extracting the value of a field from a record (product type value).
-**Div** notation, e.g., 
+**Div** notation, e.g.,
 
 ```k
  / variant_name
 ```
 
 is used for asserting a particular variant of a union and extracting its value.
-Product type `{ T₁ l₁, T₂ l₂, … , Tₙ lₙ }` naturally defines `n` partial functions: `.l₁, .l₂, … , .lₙ`,  
-and union type `< T₁ l₁, T₂ l₂, … , Tₙ lₙ >` naturally defines `n` partial functions `/l₁, /l₂, … , /lₙ`.
+A product type `{ T₁ l₁, T₂ l₂, … , Tₙ lₙ }` naturally defines `n` partial functions: `.l₁, .l₂, … , .lₙ`,
+and a union type `< T₁ l₁, T₂ l₂, … , Tₙ lₙ >` naturally defines `n` partial functions `/l₁, /l₂, … , /lₙ`.
 Those partial functions are called **projections** and they constitute the basis for the definition
 of all other partial functions in the `k` language.
 
@@ -81,10 +81,10 @@ Expressions combine partial functions using the following operators:
 Parentheses around a composition may be omitted except for the empty composition `()` — the identity function.
 Empty product, `{ }`, defines a constant function (ignoring its input) returning *unit*.
 
-It is important to notice that after the three markers: `dot (.)`, `div (/)`, or `pipe (|)`, there must be a constant label literal. For that reason, it is possible and advised not to leave any blanks after the marker, e.g.:
+It is important to notice that after the three markers `dot (.)`, `div (/)`, or `pipe (|)`, there must be a constant label literal. For that reason, it is possible and recommended not to leave any blanks after the marker, e.g.:
 
 ```k-lang
-  .field /'a-tag' |"strange and long tag name ✅" 
+  .field /'a-tag' |"strange and long tag name ✅"
 ```
 
 ---
@@ -105,7 +105,7 @@ This defines a "two-variant" union type and three functions: two constants and o
 ## **2.7 Summary**
 
 * All types describe tree shapes.
-* As type expression, `{}` is the empty product type (with one value, called *unit*).
+* As a type expression, `{}` is the empty product type (with one value, called *unit*).
 * Functions, not values, are the only expressions in `k`.
 
 ---

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

@@ -2,7 +2,7 @@
 
 ## **3.1 Motivation**
 
-A type in `k` describes a set of finite labeled trees, which can be recognized by a finite tree automaton (FTA). Equivalently, a type definition can be seen as a Context-Free Grammar (CFG), where the values of the type are the derivation trees of the grammar.
+A type in `k` describes a set of finite labeled trees, which can be recognized by a finite tree automaton (FTA). Equivalently, a type definition can be seen as a context-free grammar (CFG), where the values of the type are the derivation trees of the grammar.
 
 For example, the recursive type definition of a `list`:
 
@@ -31,7 +31,7 @@ A value of type `list` is a derivation tree of this grammar. For instance, a lis
                      -- (rule 1) --> {} |true
 ```
 
-This derivation tree corresponds to the value generated by constant function: `{ {} |true head, {} |nil tail } |cons`.
+This derivation tree corresponds to the value generated by the constant function `{ {} |true head, {} |nil tail } |cons`.
 
 Representing types as automata (or CFGs) provides each type with a well-defined structure, independent of the names used in the source code. This allows for canonical normal forms and for comparing types for equality by structure alone.
 

package/DOCS/book/04-partial-functions-and-composition.md

@@ -91,7 +91,7 @@ Here, `true_bool` and `false_bool` are constant functions. They are also **total
 
 ---
 
-## **4.6  Projection and Variant Value constructor**
+## **4.6  Projection and variant value constructors**
 
 Projection selects a field or a variant from a product or union.
 It is written with a leading dot `.` or a leading slash `/`, respectively:
@@ -141,6 +141,6 @@ The empty product `{}` is the constant function returning the unit value.
 * **Product composition** `{...}` runs functions in parallel and gathers their results.
 * **Union composition** `<...>` tries functions in order, returning the first successful result.
 * **Projections** (`.x`, `/x`) are fundamental building blocks for accessing data structures.
-* **Variant constructor** (`|tag`) allows lifting a value into a variant type value.
+* **Variant constructors** (`|tag`) allow lifting a value into a variant type value.
 
 ---

package/DOCS/book/05-typing-filters-and-normalization.md

@@ -87,13 +87,13 @@ Here:
 
 ## **5.6 Type inference and normalization**
 
-Every `k` program can be analyzed to assign an input and an output filter to every sub-expression. This process is called type inference abd normalization.
+Every `k` program can be analyzed to assign an input and an output filter to every sub-expression. This process is called type inference and normalization.
 
-Type inference and normalization proceeds as follows:
+Type inference and normalization proceed as follows:
 
 1. Build a graph of all type references appearing explicitly and implicitly in the program.
 2. Annotate each expression node with a pair of (input filter, output filter).
-3. Replace filters that match a single, concrete type with that type expression, adding any newly-discovered types to the graph.
+3. Replace filters that match a single, concrete type with that type expression, adding any newly discovered types to the graph.
 4. Repeat until a fixed point is reached and no more changes occur.
 5. Compute canonical forms for all newly introduced types.
 

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

@@ -138,7 +138,7 @@ The value `{}|_|0|1` or in JSON-like notation `{1:{0:{_:{}}}}` (binary 10₂ = d
 01 00 10
 ```
 
-This represents the left-most derivation of  `{}|_|0|1` from `C0`.
+This represents the leftmost derivation of `{}|_|0|1` from `C0`.
 
 #### **Prefix-free property**
 
@@ -304,7 +304,7 @@ Without DAG: Each "Engineering" string encoded separately
 - 1000 records × 30 bytes/record = 30KB
 
 With DAG: "Engineering" string shared via back-references  
-- 1 × "Engineering" (11 bytes) + 800 × back-reference (3 bytes) = 2.4KB
+- 1 × "Engineering" (11 bytes) + 800 × back-reference (3 bytes) = 2.4 KB
 - Compression ratio: ~12.5×
 ```
 
@@ -1061,7 +1061,7 @@ The final encoding strategy balances theoretical optimality with practical hardw
 - **Decode performance**: 5-10× faster than bit-level encoding  
 - **Cache behavior**: Excellent (word-aligned, sequential access)
 - **SIMD compatibility**: Yes (bulk discriminator processing)
-- **Architecture agnostic**: Optimized for x86-64 and ARM64
+- **Architecture-agnostic**: Optimized for x86-64 and ARM64
 
 **Performance characteristics**:
 

package/DOCS/book/07-the-partial-function-abi.md

@@ -3,7 +3,7 @@
 ## **7.1  Purpose**
 
 The **application binary interface (ABI)** defines how partial functions in `k` are represented and invoked at runtime.
-Its goal is to make all functions - whether user-defined or compiled - compatible with the same calling convention and data layout.
+Its goal is to make all functions, whether user-defined or compiled, compatible with the same calling convention and data layout.
 
 Every compiled `k` function receives a single argument (a runtime value) and may either produce a result or remain undefined.
 The ABI provides a uniform way to express both outcomes.

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

@@ -133,7 +133,7 @@ otherwise it is an identity
 ⟨ ?F , v ⟩ ⇓ v
 ```
 
-Filters therefore act as compile time annotations for type checking only.
+Filters therefore act as compile-time annotations for type checking only.
 As operations they are identities at run time, unless they lead to fully typed
 expressions (i.e., can be replaced by a type). Their pattern information may
 still be present on the runtime value because values can carry codec patterns.

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

@@ -44,7 +44,7 @@ Each stage transforms one representation of the program into another, simpler on
 
 A minimal compiler can be viewed as three connected modules:
 
-* **Front end** — reads source code, builds the AST, performs type analysis.
+* **Front end** — reads source code, builds the AST, and performs type analysis.
 * **Middle** — resolves all references, normalizes types, and simplifies expressions.
 * **Back end** — produces the executable form.
 
@@ -107,7 +107,7 @@ For `k`, the IR mirrors the structure of partial functions:
 
 | Concept in k          | IR operation                     |
 | --------------------- | -------------------------------- |
-| Projection `.x` '/x'  | `PROJECT label_id`               |
+| Projection `.x` `/x`  | `PROJECT label_id`               |
 | Composition `(f g)`   | `CALL f; CALL g`                 |
 | Union `<f,g>`         | `TRY f; IF undefined THEN TRY g` |
 | Product `{.x f, .y g}` | `PRODUCT_CALL (f, g); COMBINE`   |

package/DOCS/book/appendix-b-incorporating-external-predefined-types-and-functions.md

@@ -1,4 +1,5 @@
 # Appendix B — Incorporating External Predefined Types and Functions
+
 ## **B.1  Purpose**
 
 The k language is intentionally minimal.

package/README.md

@@ -40,13 +40,12 @@ numbers are either `0` or one more than another natural number:
 
 ```k
 $ nat = < {} 0, nat +1 >;
-
-zero = {} |0;
-inc = |+1;
-
-add = ?X <
-  { .x /+1 x, .y inc y } ?X add,
-  .y
+0 = {} | 0 $ nat ;
+inc = | +1 $ nat ;
+dec = $ nat / +1 ;       # undefined for '0'
+add = $ { nat x, nat y } <
+  { . x dec x, . y inc y } add,    # defined if 'x > 0'
+  . y                              # else, return 'y'
 >;
 ```
 
@@ -240,7 +239,7 @@ Still evolving:
 - optimization and backend experiments
 - larger real-world examples
 
-## Good Areas For Contributors
+## Good Areas for Contributors
 
 k is small enough to study, but there are several useful directions:
 

package/a.k

@@ -0,0 +1,138 @@
+----- codes -----
+$ 2aks = {VtPH "factor", Envk "i"};
+$ 2xPW = {PHbG "r", VtPH "x"};
+$ 33dY = {VtPH "_x", VtPH "result", VtPH "y"};
+$ 6d2A = {NiDZ "if", nh8T "then"};
+$ 8MHR = {VtPH "if", 9bLM "then"};
+$ 9bLM = < NiDZ "no", NiDZ "yes" >;
+$ CuVs = {VtPH "k", VtPH "x"};
+$ ERx5 = {Mjus "c", VtPH "x", VtPH "y"};
+$ Envk = {VtPH "log", Nws3 "res", VtPH "step", VtPH "x"};
+$ EvuD = {VtPH "if", VtPH "then"};
+$ F7RN = < NiDZ "+", NiDZ "-" >;
+$ FL4i = {nh8T "res_wo_sign", F7RN "sign"};
+$ H24y = {VtPH "if", Nws3 "then"};
+$ Hj9J = {NiDZ "if", Nws3 "then"};
+$ KxW7 = {VtPH "log", VtPH "step", VtPH "x"};
+$ Ljf9 = {VtPH "car", PHbG "cdr"};
+$ Mjus = < NiDZ "0", NiDZ "1" >;
+$ NiDZ = {};
+$ Nws3 = < VtPH "+", VtPH "-" >;
+$ PHbG = < Ljf9 "cons", NiDZ "nil" >;
+$ R7RD = {VtPH "x", VtPH "y"};
+$ RLhu = {NiDZ "if", R7RD "then"};
+$ RknV = {VtPH "if", PHbG "then"};
+$ S5nE = {Nws3 "int", muqD "rat"};
+$ TcsE = {muqD "x", muqD "y"};
+$ Thzc = {VtPH "r", VtPH "x"};
+$ UFVU = {VtPH "_x", Nws3 "k"};
+$ Vc85 = {Nws3 "x", Nws3 "y"};
+$ VtPH = < VtPH "0", VtPH "1", NiDZ "_" >;
+$ WWuP = {muqD "x", Nws3 "y"};
+$ YeUu = {VtPH "and", VtPH "if"};
+$ YfKH = {VtPH "d", VtPH "n"};
+$ ZLDk = {VtPH "step", VtPH "x"};
+$ bSFt = {NiDZ "and", VtPH "if", VtPH "then"};
+$ dXdV = {9bLM "inOrder", VtPH "x", VtPH "y"};
+$ eYsq = {NiDZ "if", VtPH "then"};
+$ hJHA = {R7RD "if", VtPH "then"};
+$ hPpx = {Nws3 "if", nh8T "then"};
+$ muqD = {Nws3 "d", Nws3 "n"};
+$ nPgb = {Nws3 "lcm", muqD "x", muqD "y"};
+$ nh8T = {Nws3 "div", VtPH "rem"};
+$ nhfK = {VtPH "and", VtPH "if", VtPH "then"};
+$ prGg = {Vc85 "fib(n),fib(n.1)", VtPH "n"};
+$ s7Sd = {Nws3 "res", VtPH "step", VtPH "x"};
+$ sqr8 = {VtPH "if", F7RN "then"};
+$ uMrJ = {VtPH "if", muqD "then"};
+$ yYPm = {VtPH "result", F7RN "sign"};
+$ zLbj = {Nws3 "d", nh8T "div", Nws3 "n"};
+----- rels -----
+8jvS = ?(...) 4Uqf mx7B ?<<$NiDZ _, ...> 0, ...>;
+TLyi = ?(...) 8jvS 7GtG $VtPH;
+2ezj = ?(...) TLyi 7GtG $VtPH;
+BHYs = ?(...) 2ezj 7GtG $VtPH;
+XeYK = ?(...) BHYs 7GtG $VtPH;
+ycSP = ?(...) XeYK 7GtG $VtPH;
+c3fq = ?(...) ycSP 7GtG $VtPH;
+ANDv = ?(...) c3fq 7GtG $VtPH;
+BASZ = ?(...) ANDv 7GtG $VtPH;
+Je6N = ?(...) BASZ 7GtG $VtPH;
+PaZn = ?(...) Je6N 7GtG $VtPH;
+8Wzq = ?(...) PaZn 7GtG $VtPH;
+7gmR = ?(...) 8Wzq 7GtG $VtPH;
+SCqj = ?<$NiDZ no, $NiDZ yes, ...> </yes |no, /no |yes> $9bLM;
+KWT2 = ?(...) {} |yes $9bLM;
+7RTv = ?(...) KWT2 SCqj $9bLM;
+L8iN = ?<{(...) car, X0 cdr} cons, $NiDZ nil>=X0 () ?<{(...) car, X0 cdr} cons, $NiDZ nil>=X0;
+tyxZ = ?(...) {} |nil ?<{(...) car, X0 cdr} cons, $NiDZ nil>=X0;
+C9mM = ?(...) {() car, tyxZ cdr} |cons ?<{(...) car, X0 cdr} cons, $NiDZ nil>=X0;
+w6w6 = ?{X0 car, <{X0 car, X1 cdr} cons, $NiDZ nil>=X1 cdr, ...} {.car car, .cdr cdr} |cons ?<{(...) car, X0 cdr} cons, $NiDZ nil>=X0;
+jhbb = ?<{(...) car, X0 cdr} cons, $NiDZ nil>=X0 /nil tyxZ ?<{(...) car, X0 cdr} cons, $NiDZ nil>=X0;
+UY5b = ?<{(...) car, X0 cdr} cons, $NiDZ nil>=X0 /cons .car ?(...);
+S7xP = ?<{(...) car, X0 cdr} cons, $NiDZ nil>=X0 /cons .cdr ?<{(...) car, X0 cdr} cons, $NiDZ nil>=X0;
+4Uqf = ?(...) {} |_ ?<$NiDZ _, ...>;
+J6xt = ?(...) |1 ?<(...) 1, ...>;
+mx7B = ?(...) |0 ?<(...) 0, ...>;
+7GtG = $VtPH {4YaF x, 4Uqf y} JfKb $VtPH;
+ZTFs = $VtPH </_ KWT2, 7RTv> $9bLM;
+AkEL = $VtPH {ZTFs /yes if, () then} .then $VtPH;
+fKyL = $R7RD {.x 4YaF x, .y y} N8w3 $VtPH;
+N8w3 = $R7RD <{.x /0 x, .y mx7B y} N8w3, {.x /1 x, .y J6xt y} N8w3, .y> $VtPH;
+4YaF = $VtPH {() x, 4Uqf r} NbnA $VtPH;
+NbnA = $Thzc <{.x /0 x, .r mx7B r} NbnA, {.x /1 x, .r J6xt r} NbnA, .r> $VtPH;
+vbhA = $R7RD {.x 4YaF x, .y 4YaF y, KWT2 inOrder} CaAi $9bLM;
+CaAi = $dXdV <{.x /0 x, .y /0 y, .inOrder inOrder} CaAi, {.x /1 x, .y /1 y, .inOrder inOrder} CaAi, {.x /0 x, .y /1 y, .inOrder inOrder} CaAi, {.x /1 y, .y /0 x, .inOrder SCqj inOrder} CaAi, {.x </0, /1> if, .inOrder SCqj then} .then, .inOrder> $9bLM;
+6rrB = $R7RD {vbhA /no if, () then} .then $R7RD;
+y3WV = $R7RD 6rrB {.x y, .y x} 6rrB $R7RD;
+fSRE = $VtPH {4YaF x, tyxZ r} 9hTs $PHbG;
+9hTs = ?{$PHbG r, $VtPH x, ...} <{.x AkEL if, .r then} .then, {.x /0 x, {8jvS car, .r cdr} w6w6 r} 9hTs, {.x /1 x, {TLyi car, .r cdr} w6w6 r} 9hTs> $PHbG;
+Ywaf = ?<{<(...) 0, (...) 1, ...> car, X0 cdr} cons, $NiDZ nil>=X0 <S7xP <{UY5b /0 if, S7xP Ywaf mx7B then} .then, {UY5b /1 if, S7xP Ywaf J6xt then} .then>, 4Uqf> $VtPH;
+Prn6 = ?<X0 0, ...>=X0 </0 Prn6, ()> ?<X0 0, ...>=X0;
+xX22 = $VtPH Prn6 <AkEL 8jvS, ()> $VtPH;
+Phke = $VtPH xX22 |+ $Nws3;
+xdAf = $Nws3 </+, /-> $VtPH;
+JyBD = $Nws3 {7sp2 /+ if, () then} .then $Nws3;
+BzLM = $Nws3 {/- if, () then} .then $Nws3;
+NxZn = $Nws3 {/+ /0 AkEL if, () then} .then $Nws3;
+NKnM = $Nws3 {/- /1 AkEL if, () then} .then $Nws3;
+6VKZ = $Nws3 </+ {4YaF x, 4Uqf y} JfKb |+, NKnM 8jvS Phke, /- {4YaF x, 4Uqf y} 9Cyq |-> $Nws3;
+JfKb = $R7RD <{.x /0 x, .y J6xt y} N8w3, {.x /1 x, .y mx7B y} JfKb, .y J6xt> $VtPH;
+7sp2 = $Nws3 <NxZn TLyi |-, /+ {4YaF x, 4Uqf y} 9Cyq |+, /- {4YaF x, 4Uqf y} JfKb |-> $Nws3;
+9Cyq = ?{$VtPH x, $VtPH y, ...} <{.x /1 x, .y mx7B y} N8w3, {.x /0 x, .y J6xt y} 9Cyq> $VtPH;
+vvzA = ?(...) {} |0 $Mjus;
+nXAf = ?(...) {} |1 $Mjus;
+APnt = $Vc85 <{.x /+ 4YaF x, .y /+ 4YaF y, vvzA c} 73G3 4YaF xX22 |+, {.x /- 4YaF x, .y /- 4YaF y, vvzA c} 73G3 4YaF xX22 |-, {.y /- x, .x /+ y} 6rrB {.x 4YaF x, .y 4YaF y, vvzA c} 3kn7 4YaF xX22 |-, {.x /+ 4YaF x, .y /- 4YaF y, vvzA c} 3kn7 4YaF xX22 |+, {.x /- x, .y /+ y} 6rrB {.x 4YaF x, .y 4YaF y, vvzA c} 3kn7 4YaF xX22 |-, {.y /+ 4YaF x, .x /- 4YaF y, vvzA c} 3kn7 4YaF xX22 |+> $Nws3;
+4ZfX = $Nws3 <NxZn, /+ |-, /- |+> $Nws3;
+kBAy = $Vc85 {.x x, .y 4ZfX y} APnt $Nws3;
+73G3 = $ERx5 <{.x AkEL if, .y AkEL and, <.c /0 8jvS, TLyi> then} .then, {.x AkEL if, .c /0 and, .y then} .then, {.x y, .y AkEL x, .c c} 73G3, {<.c /0 8jvS, TLyi> x, .y y, .x AkEL vvzA c} 73G3, {.x /0 x, .y /0 y, .c /0 vvzA c} 73G3 mx7B, {.x /0 x, .y /0 y, .c /1 vvzA c} 73G3 J6xt, {.x /0 x, .y /1 y, .c /0 vvzA c} 73G3 J6xt, {.x /0 x, .y /1 y, .c /1 nXAf c} 73G3 mx7B, {.x /1 x, .y /0 y, .c /0 vvzA c} 73G3 J6xt, {.x /1 x, .y /0 y, .c /1 nXAf c} 73G3 mx7B, {.x /1 x, .y /1 y, .c /0 nXAf c} 73G3 mx7B, {.x /1 x, .y /1 y, .c /1 nXAf c} 73G3 J6xt> $VtPH;
+3kn7 = $ERx5 <{.x then, .y AkEL if, .c /0 and} .then, {.x /1 then, .y AkEL if, .c /1 and} .then mx7B, {.x /0 x, .y AkEL y, .c /1 nXAf c} 3kn7 J6xt, {.x /0 x, .y /0 y, .c /0 vvzA c} 3kn7 mx7B, {.x /0 x, .y /0 y, .c /1 nXAf c} 3kn7 J6xt, {.x /0 x, .y /1 y, .c /0 nXAf c} 3kn7 J6xt, {.x /0 x, .y /1 y, .c /1 nXAf c} 3kn7 mx7B, {.x /1 x, .y /0 y, .c /0 vvzA c} 3kn7 J6xt, {.x /1 x, .y /0 y, .c /1 vvzA c} 3kn7 mx7B, {.x /1 x, .y /1 y, .c /0 vvzA c} 3kn7 mx7B, {.x /1 x, .y /1 y, .c /1 nXAf c} 3kn7 J6xt> $VtPH;
+NiRD = ?(...) {} |+ $F7RN;
+u9uY = ?(...) {} |- $F7RN;
+JEEj = $Nws3 </+ NiRD, /- u9uY> $F7RN;
+3PYm = $Vc85 {<{.x /+ if, .y /+ and} NiRD, {.x /- if, .y /- and} NiRD, u9uY> sign, {8jvS result, .x xdAf 4YaF _x, .y xdAf y} 9bpS result} <{.sign /+ if, .result 4YaF Phke then} .then, {.sign /- if, .result 4YaF Phke 4ZfX then} .then> $Nws3;
+9bpS = $33dY <{.y AkEL if, .result then} .then, {.result mx7B result, ._x _x, .y /0 y} 9bpS, {{._x x, .result mx7B y, vvzA c} 73G3 result, ._x _x, .y /1 y} 9bpS> $VtPH;
+TPzm = $R7RD _log! <{.y x, .x y} 6rrB .y, {{{.x Phke x, .y Phke y} kBAy /+ x, .y 4YaF mx7B 4YaF y} TPzm x, .y y} TPzm> $VtPH;
+Vs6b = $R7RD <{.y x, .x y} 6rrB, ()> Ah93 $VtPH;
+Ah93 = $R7RD <{.y /0 if, .x then} .then, {.y x, TPzm y} Ah93> $VtPH;
+nB9M = $ZLDk {.x x, .step step, 8jvS log} 5ivr $VtPH;
+5ivr = ?{$VtPH log, $VtPH step, $VtPH x, ...} <{{.step x, .x y} 6rrB if, .log then} .then, {.x x, {.step x, 8jvS y} 6rrB {.x x, 2ezj y} {.x Phke x, .y Phke y} 3PYm xdAf step, .log Phke 6VKZ xdAf log} 5ivr> $VtPH;
+MTKW = $CuVs {.x 4YaF _x, .k Phke k} au4T 4YaF $VtPH;
+au4T = ?{<X0 0, ...>=X0 _x, $Nws3 k, ...} <{.k NxZn if, ._x then} .then, {._x mx7B _x, .k 7sp2 k} au4T> ?<X0 0, ...>=X0;
+Bs2e = $Vc85 {<{.x /+ if, .y JEEj then} .then, {.x /- if, .y 4ZfX JEEj then} .then> sign, {.x xdAf x, .y xdAf step, 8jvS Phke res} 8Dwz res_wo_sign} <{.sign /+ if, {.res_wo_sign .div div, .res_wo_sign .rem rem} then} .then, {.res_wo_sign .div 4ZfX div, .res_wo_sign .rem rem}> $nh8T;
+8Dwz = ?{$Nws3 res, $VtPH step, $VtPH x, ...} {.x x, .step step, .res res, {.x x, .step step} nB9M log} <{.log Phke NxZn if, {.res div, .x rem} then} .then, {{TLyi x, .log Phke 7sp2 xdAf k} MTKW factor, () i} {{.i .x Phke x, {.i .step Phke x, .factor Phke y} 3PYm y} kBAy xdAf x, .i .step step, {.i .res x, .factor Phke y} APnt res} 8Dwz> $nh8T;
+GSLa = $R7RD {{.x Phke x, .y Phke y} 3PYm x, Vs6b Phke y} Bs2e .div xdAf $VtPH;
+FaWv = $Nws3 <NxZn TLyi Phke, /+ Phke {7sp2 FaWv x, () y} 3PYm> $Nws3;
+HZYv = ?{$Vc85"fib(n),fib(n.1)", $VtPH n, ...} <{.n Phke 7sp2 /+ n, ."fib(n),fib(n.1)" {APnt x, .x y}"fib(n),fib(n.1)"} HZYv, ."fib(n),fib(n.1)"> $Vc85;
+aUJp = $VtPH {() n, {TLyi Phke x, 8jvS Phke y}"fib(n),fib(n.1)"} HZYv .x $Nws3;
+sghj = $YfKH {.n Phke n, .d Phke d} 2zFi $muqD;
+2zFi = $muqD <{.d /- if, {.n 4ZfX n, .d 4ZfX d} then} .then, ()> {() x, {.n xdAf x, .d xdAf y} Vs6b Phke y} {{.x .n x, .y y} Bs2e .div n, {.x .d x, .y y} Bs2e .div d} $muqD;
+Jn92 = $TcsE {.x x, .y y, {.x .d xdAf x, .y .d xdAf y} GSLa Phke lcm} {{{.x .n x, {.lcm x, .x .d y} Bs2e .div y} 3PYm x, {.y .n x, {.lcm x, .y .d y} Bs2e .div y} 3PYm y} APnt n, .lcm d} 2zFi $muqD;
+2Uyd = $TcsE {{.x .n x, .y .n y} 3PYm n, {.x .d x, .y .d y} 3PYm d} 2zFi $muqD;
+uRTk = $TcsE {.x x, .y {.n 4ZfX n, .d d} y} Jn92 $muqD;
+FtdC = $muqD {.d n, .n d} 2zFi $muqD;
+MH4q = $TcsE {.x x, .y FtdC y} 2Uyd $muqD;
+8jRf = $muqD {.n n, .d d, {.n x, .d y} Bs2e div} {.div .div int, {.div .rem Phke n, .d d} rat} $S5nE;
+
+()
+