@fraczak/k 6.10.5 → 7.0.0

package/DOCS/DIVERGENCE_DETECTION.md

@@ -16,7 +16,6 @@ Define `HEAD` as the set of direct first ref calls:
 ```
 HEAD(ref(X)) = {X}
 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, ...>) = {}   -- the head of a union is the empty set

package/DOCS/FILE_FORMATS.md

@@ -397,13 +397,13 @@ hash without `--export`.
 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 >`.
+- `5` and `10` are nullary relations (constants) of type `{} -> 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 "+", 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`.
+  relation of type `{} -> int`.
 
 ### 3. Constant Expressions vs. Stream Transformers
 - **Stream Transformers:** An expression using the identity relation `()`
@@ -412,7 +412,7 @@ they are defined relations (aliases) in `Examples/arithmetics.k`:
   `./codecs/int.mjs --parse`).
 - **Closed Constant Relations:** A relation with no free inputs (such
   as `{10 int x, 5 int y} plus`) is a constant relation with input
-  type of unit `${}`. When executed through `./k.mjs`, it expects
+  type of unit `{}`. When executed through `./k.mjs`, it expects
   an empty unit `{}` on `stdin`:
   ```bash
   echo "{}" | node codecs/k-parse.mjs | \

package/DOCS/KIR_SPECIALIZATION_DESIGN.md

@@ -396,7 +396,7 @@ Runtime:
 
 Typing and patterns:
 
-- `$type` filter;
+- `?filter` expression;
 - open product filter;
 - open union filter;
 - recursive list/tree filter;

package/DOCS/OBJECT_FILE_AND_PATTERN.md

@@ -5,7 +5,7 @@ The codec boundary is no longer a JSON object. A serialized value is one binary
 stream:
 
 ```text
-encode($pattern_value : $pattern) encode(value : decoded_pattern)
+encode(pattern_value : pattern) encode(value : decoded_pattern)
 ```
 
 The pattern is the framing protocol. There is no separate envelope type.
@@ -15,10 +15,10 @@ 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, edges cdr } cons >;
+edge = ?{ string label, bits target };
+edges = ?< {} nil, { edge car, E cdr } cons > = E;
 
-$ pattern-node = <
+pattern-node = ?<
   {} any,
   edges open-product,
   edges open-union,
@@ -26,24 +26,24 @@ $ pattern-node = <
   edges closed-union
 >;
 
-$ pattern = < {} nil, { pattern-node car, pattern cdr } cons >;
+pattern = ?< {} nil, { pattern-node car, P cdr } cons > = P;
 ```
 
 This does not mean `core.k` is pre-loaded into ordinary program execution. The
 special role of `core.k` here is that the wire codec relies on the canonical
-`$pattern` definition from that file.
+`pattern` definition from that file.
 
 In this schema:
 
 - the first pattern-list element is node `0`, the root,
-- an edge target is a node index encoded as `$bits`,
-- labels are `$string` values and therefore Unicode scalar-value strings,
+- an edge target is a node index encoded as `bits`,
+- labels are `string` values and therefore Unicode scalar-value strings,
 - edge lists are sorted by label,
 - `any` carries no edges,
 - the four product/union node kinds carry their edge list directly.
 
-The fixed singleton pattern of `$pattern` is the first decoder context for all
-k wire values. Decoding any value first decodes a `$pattern` value under that
+The fixed singleton pattern of `pattern` is the first decoder context for all
+k wire values. Decoding any value first decodes a `pattern` value under that
 constant, then decodes the remaining bits under the pattern just obtained.
 
 ## Debug Notation
@@ -69,7 +69,7 @@ The parser plus type-derivation phase should eventually emit an object value
 rather than executable JavaScript structures. A minimal first object shape is:
 
 ```k
-$ object-file = {
+object-file = ?{
   pattern input-pattern,
   pattern output-pattern,
   pattern value-pattern
@@ -274,7 +274,7 @@ For a definitions-only source file:
 
 ```k
 -- defs.k
-$ nat = <{} zero, nat succ>;
+nat = ?< {} zero, N succ > = N;
 succ = |succ;
 ```
 

package/DOCS/PATTERNS.md

@@ -1,12 +1,13 @@
-# Patterns
+# Schemas and Pattern Graphs
 
-A pattern describes the shape of values that may flow through a k
-expression. Patterns 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 type-derivation engine
+- the contract-derivation engine
 - the binary codec
-- runtime values carried by the codec pipeline
-- filter expressions
+- runtime framed values `(schema, payload)`
+- filter expressions (`?schema`)
 
 ## Pattern Kinds
 
@@ -49,19 +50,19 @@ This is not the wire format. It is the canonical readable export form.
 
 A k script can describe a pattern through:
 
-- a type name in terminal position
+- a relation in terminal position
 - a filter expression in terminal position
 
 Examples:
 
 ```k
-$ bits = < {} _, bits 0, bits 1 >;
-$ list = < {} nil, { bits car, list cdr } cons >;
+bits = ?< {} _, bits 0, bits 1 > = bits;
+list = ?< {} nil, { < {} _, B 0, B 1 >=B car, L cdr } cons > = L;
 list
 ```
 
 ```k
-?< {} nil, { $bits car, X cdr } cons > = X
+?< {} nil, { < {} _, B 0, B 1 >=B car, X cdr } cons > = X
 ```
 
 In both cases, the compiler derives a root pattern from `__main__`.
@@ -78,14 +79,14 @@ It:
 3. resolves `__main__`
 4. requires `__main__` to be either:
    - a filter expression
-   - a type name
+   - a relation name
 5. exports the corresponding root pattern
 6. prints it as the canonical property-list array
 
 Example:
 
 ```bash
-echo '?< {} nil, { $bits car, X cdr } cons > = X' | node ./patterns/from-k.mjs
+echo '?< {} nil, { < {} _, B 0, B 1 >=B car, X cdr } cons > = X' | node ./patterns/from-k.mjs
 ```
 
 Typical output:
@@ -94,20 +95,19 @@ Typical output:
 [["closed-union",[["nil",1],["cons",2]]],["closed-product",[]],["closed-product",[["car",3],["cdr",0]]],["closed-union",[["_",1],["0",3],["1",3]]]]
 ```
 
-## Patterns in the Codec
+## Schemas in the Codec
 
 The active wire format is:
 
 ```text
-encode($pattern_value : $pattern) encode(value : decoded_pattern)
+encode(schema_value : schema) encode(payload : decoded_schema)
 ```
 
 So the property-list array printed by `patterns/from-k.mjs` is a
-readable externalization of the same pattern information carried in the
+readable externalization of the same schema information carried in the
 wire stream.
 
-`k-parse --input-pattern ...` and `k-parse --input-type ...` both
-ultimately produce the same kind of root pattern used to interpret
+`k-parse --input-pattern ...` produces the root schema used to interpret
 textual values.
 
 ## See Also

package/DOCS/PATTERNS_AND_TYPED_VALUES.md

@@ -243,7 +243,7 @@ PolyVal(P) = { (P, (T, t)) : T ⊨ P and t ∈ Tree(T) }.
 In the current JavaScript implementation, this semantic pair is represented
 directly in memory: `Product` and `Variant` carry the witness tree, and every
 `Value` may also carry the root pattern as `value.pattern`. The codec stream is
-the serialized form of the same object: an encoded `$pattern` value followed by
+the serialized form of the same object: an encoded `pattern` value followed by
 the value payload interpreted under that pattern.
 
 So a pattern does not denote a set of raw trees.

package/DOCS/REPL.md

@@ -7,7 +7,7 @@ The interpreter keeps a live `.klib`-style state in memory:
 
 - registered codes
 - compiled relations
-- human aliases for both
+- human aliases for relations
 - metadata origins used to recover aliases
 - the current value flowing through the session
 
@@ -33,14 +33,10 @@ is complete.
 | Command | Meaning |
 | --- | --- |
 | `:help` | Show command summary |
-| `:engine [wasm\|js]` | Display or switch evaluation engine (`wasm` or `js`) |
+| `:engine [wasm|js]` | Display or switch evaluation engine (`wasm` or `js`) |
 | `:wasm` / `:js` | Shortcut to switch engine |
 | `:rel name` | Show relation definition |
-| `:type name` | Show the canonical definition of a type |
-| `:types` | List type aliases |
 | `:rels` | List relation aliases |
-| `:code name` | Alias for `:C name` |
-| `:C name` | Show canonical code definition |
 | `: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`) |
@@ -62,13 +58,12 @@ Examples:
 ```
 
 ```k
-> $ bool = <{} true, {} false>;
+> bool = ?<{} true, {} false>;
 ```
 
 ```k
-> $ bool = <{} true, {} false>
-  ; not = $bool </true | false, {} | true >
-  ; {} |true not
+> not = ?<{} true, {} false> < /true | false, /false | true >;
+  {} |true not
 ```
 
 The interpreter uses these rules, in order:
@@ -95,9 +90,7 @@ growing the live library context.
 
 The interpreter keeps:
 
-- `codes`: canonical code definitions
 - `rels`: canonical compiled relations
-- `typeAliases`: human type names to canonical hashes
 - `relAliases`: human relation names to canonical hashes
 - `value`: current value, initially `{}`
 
@@ -113,12 +106,12 @@ Before compiling user input, the interpreter injects an alias preamble
 so human names can be reused naturally:
 
 ```k
-$ nat = @...;
+nat = @...;
 succ = @...;
 <user snippet>
 ```
 
-Type aliases use `$ name = @hash;`. Relation aliases use `name = @hash;`.
+Relation aliases use `name = @hash;`.
 
 Diagnostic locations are remapped back to the visible user snippet, so
 error line numbers do not count the hidden preamble.
@@ -129,12 +122,9 @@ Tab completion covers:
 
 - command names after `:`
 - file paths for `:load`, `:klib`, and `:ko`
-- type aliases
 - relation aliases
 - canonical names beginning with `@`
 
-Type aliases also complete in `$name` position inside raw k input.
-
 For codec commands, completion covers `:codec load`, `:codec unload`,
 `:codec list`, file paths after `:codec load`, and codec names after
 `:input`.
@@ -157,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 = < {} _, bits 0, bits 1 >`).
+`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.
@@ -319,7 +309,7 @@ Evaluated values print in k syntax together with the inferred envelope:
 ## Example Session
 
 ```text
-> $ nat = < {} 0, nat +1 >;
+> nat = ?< {} 0, N +1 > = N;
 > inc = | +1;
 > {} | 0
 {}|0 ?<{} 0, ...>

package/DOCS/TYPE_DERIVATION.md

@@ -142,19 +142,13 @@ out(f) = LOOKUP(out(f))
 Once the type derivation for the defining expression for `f` is done, the
 input and output patterns are stored and will be used.
 
-### Type `$ T`
-
-```text
-in(T) = out(T) = pattern(T)
-```
-
 ### Filter `? F`
 
 ```text
-see patterns.filterToPattern(F)
+in(? F) = out(? F) = pattern(F)
 ```
 
-A filter expression is syntax for describing pattern graphs.
+A filter expression `? F` describes pattern graphs, acting as an identity filter that constrains inputs and outputs to pattern `F`.
 
 ## 6. Global Algorithm
 

package/DOCS/WEB_REPL_REQUIREMENTS.md

@@ -16,7 +16,7 @@ The scope encompasses four primary objectives:
 3. **Curate VFS Files**: Restrict the bundled Virtual File System (VFS) to verified, useful `.k` files (`core.k`, `Examples/arithmetics.k`, `Examples/ieee.k`, `Examples/poly.k`), auditing and verifying types used by REPL codecs.
 4. **Automatic Dependency Loading & Type Aliasing for Codecs**:
    - Automatically load the required `.k` source file whenever a codec is loaded, ensuring that necessary type aliases, canonical codes, and operational relations are present before the user attempts `:input` or evaluations.
-   - Establish bidirectional type alias naming so codec names are direct aliases to the underlying type hashes (e.g. `$ieee` and `$float64` both point to `@AR4s...`, `$utf8` and `$string` both point to `@Pt3Mw...`, and `$int` points to `@Nws3v...`).
+   - Establish bidirectional type alias naming so codec names are direct aliases to the underlying type hashes (e.g. `ieee` and `float64` both point to `@AR4s...`, `utf8` and `string` both point to `@Pt3Mw...`, and `int` points to `@Nws3v...`).
 
 ---
 
@@ -57,7 +57,7 @@ The scope encompasses four primary objectives:
 #### Requirements
 1. **Dropdown Ordering**: In `#example-select`, `core.k` must be the top-most option under standard examples.
 2. **Onboarding Banner**: The welcome message and quick-start hints in `browser/repl-browser.mjs` must showcase `:load core.k` as the primary recommended action.
-3. **Quick Expressions**: Ensure the quick expressions section provides expressions compatible with `core.k` out-of-the-box (e.g. `1 succ`, `10`, `$bits`, `$string`).
+3. **Quick Expressions**: Ensure the quick expressions section provides expressions compatible with `core.k` out-of-the-box (e.g. `1 succ`, `10`, `bits`, `string`).
 
 ---
 
@@ -65,9 +65,9 @@ The scope encompasses four primary objectives:
 
 #### Curated File Set
 The bundled VFS and UI examples must include only verified useful files:
-- `core.k` — The foundational standard library (bits, arithmetic on bits, Unicode `$unicode`, `$string`, `$pattern`).
-- `Examples/arithmetics.k` — Arbitrary-precision signed integers (`$int`), rationals (`$rat`), GCD/LCM, factorial, Fibonacci.
-- `Examples/ieee.k` — IEEE-754 double-precision floating point type (`$float64`) and arithmetic operations.
+- `core.k` — The foundational standard library (bits, arithmetic on bits, Unicode `unicode`, `string`, `pattern`).
+- `Examples/arithmetics.k` — Arbitrary-precision signed integers (`int`), rationals (`rat`), GCD/LCM, factorial, Fibonacci.
+- `Examples/ieee.k` — IEEE-754 double-precision floating point type (`float64`) and arithmetic operations.
 - `Examples/poly.k` — Polymorphic list functions (`concat`, `reverse`, `length`, `get_nth`, `split_by`, `take`, `drop`, `zip`).
 
 #### Dependency Management for `poly.k`
@@ -93,13 +93,13 @@ The bundled VFS and UI examples must include only verified useful files:
    Establish code aliasing so that codec names and their standard type names are both valid aliases pointing to the same canonical type hash:
    - **IEEE / Float64**:
      - Canonical Hash: `@AR4sFGMwXgjj5p7dhi8sJKDWNbrXxLefQUCBRNm5fP6t`
-     - Aliases: `$float64` and `$ieee`
+     - Aliases: `float64` and `ieee`
    - **UTF-8 / String**:
      - Canonical Hash: `@Pt3MwQwzUPxQKu58zXR3qUBHWTzfycx5bSZGzcK6EZQK`
-     - Aliases: `$string` and `$utf8`
+     - Aliases: `string` and `utf8`
    - **Int**:
      - Canonical Hash: `@Nws3vysWqC9PznraTP4kWPp44Rd77NAqrx9dgbtHAjGA`
-     - Alias: `$int`
+     - Alias: `int`
    This guarantees that both `:input utf8` and `:input string`, as well as `:input ieee` and `:input float64`, work seamlessly.
 
 3. **Idempotence**:

package/DOCS/book/01-introduction.md

@@ -33,19 +33,16 @@ We call such mappings **partial functions**.
 
 ## **1.4 Simplicity over features**
 
-`k` avoids most language constructs: no *variables* and no *control statements*.
-It has only:
+`k` avoids most traditional language constructs: no *variables*, no *loops*, and no *control flow keywords*.
+In `k`, programs are built from:
 
-1. **types** (which describe tree shapes), and
-2. **partial functions** (which transform one tree into another).
+1. **schemas** (finite tree automata describing acceptable tree payloads), and
+2. **relations** (partial mappings that transform one tree into another).
 
-These two ingredients are sufficient and powerful enough to express structured
-computation in a concise and understandable way.
+Schemas and transformations share the exact same syntax: a schema definition is simply a relation acting as a partial identity.
 
-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 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.
+The language also provides **filters** (`?schema`). Syntactically, a filter acts as a partial identity relation on payloads conforming to the schema. Semantically, filters act as **inductive termination witnesses** during contract derivation for recursive relations, while also enabling polymorphic generic programming.
+
+When analyzing a relation, the compiler derives its **contract**: a connected $(input, output)$ schema graph where shared vertices ($=X$) prove structure preservation from input through to output.
 
 ---

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

@@ -3,33 +3,33 @@
 ## **2.1 Language fragments**
 
 The `k` language has only one kind of program element: a **definition**.
-A program is a sequence of definitions of two kinds:
+A program is a sequence of definitions:
 
 ```k-lang
-$ type_name = ...type_expression... ;
-function_name = ...expression... ;
+relation_name = ...expression... ;
 ```
 
 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 separate syntax for type declarations. Data shapes are defined by the relations and pattern filters (`? ...`) that manipulate them.
 
 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.
 
 ---
 
-## **2.2 Types**
+## **2.2 Schemas**
 
-A type describes the possible **tree shapes** of values.
-Types are formed from two constructors:
+A schema describes the possible **tree shapes** of payload values.
+Schemas are formed from two constructors:
 
-1. **Product**  – written `{ T₁ l₁, T₂ l₂, … }`
+1. **Product**  – written `{ S₁ l₁, S₂ l₂, … }`
    represents records with fixed labeled fields.
 
-2. **Union**  – written `< T₁ l₁, T₂ l₂, … >`
+2. **Union**  – written `< S₁ l₁, S₂ l₂, … >`
    represents a choice between labeled alternatives.
 
 Both are finite and fully explicit.
-Every type denotes a finite tree automaton whose accepted trees are the possible values of that type.
+Every schema denotes a finite tree automaton whose accepted trees are the possible payload values of that schema.
 
 ---
 
@@ -37,12 +37,12 @@ Every type denotes a finite tree automaton whose accepted trees are the possible
 
 1. **Empty product**
    `{}` has no fields.
-   It represents the type that admits exactly one value, called *unit*.
-   There is nothing exceptional about the type and its value; it is simply the degenerate case of a product with zero fields.
+   It represents the unit schema that admits exactly one value, called *unit*.
+   There is nothing exceptional about the unit schema and its value; it is simply the degenerate case of a product with zero fields.
 
 2. **Empty union**
    `<>` has no variants.
-   It represents a type with no possible values.
+   It represents a schema with no possible values.
 
 ---
 
@@ -92,20 +92,19 @@ It is important to notice that after the three markers `dot (.)`, `div (/)`, or
 ## **2.6 Example**
 
 ```k-lang
-$ bool = < {} true, {} false >;
-true  = {} |true $ bool;
-false = {} |false $ bool;
-neg = $ bool < /true false, /false true >;
+true  = {} |true;
+false = {} |false;
+neg = < /true false, /false true >;
 ```
 
-This defines a "two-variant" union type and three functions: two constants and one transformation exchanging the variants.
+This defines three relations: two constants and one transformation exchanging the variants `/true` and `/false`. The contracts of their inputs and outputs are derived automatically by the compiler.
 
 ---
 
 ## **2.7 Summary**
 
-* All types describe tree shapes.
-* As a type expression, `{}` is the empty product type (with one value, called *unit*).
-* Functions, not values, are the only expressions in `k`.
+* All schemas describe payload tree shapes.
+* As an expression, `{}` is the empty product (with one value, called *unit*).
+* Relations, not values, are the only expressions in `k`.
 
 ---