@fraczak/k 6.0.1 → 6.0.3

package/DOCS/book-combined.html

@@ -1,3798 +0,0 @@
-<div data-align="center">
-<pre><code>      { }                         { }
-     /   \       {.lang name}      |
-   lang   by          --&gt;         name
-    |      |                       |
-   &#39;k&#39;  &#39;wojtek&#39;                  &#39;k&#39;</code></pre>
-</div>
-<h1 id="table-of-contents">Table of Contents</h1>
-<ol type="1">
-<li><a href="#chapter-1-introduction">Introduction</a></li>
-<li><a href="#chapter-2-syntax-and-values">Syntax and Values</a></li>
-<li><a href="#chapter-3-types-as-finite-automata">Types as Finite
-Automata</a></li>
-<li><a href="#chapter-4-partial-functions-and-composition">Partial
-Functions and Composition</a></li>
-<li><a href="#chapter-5-typing-filters-and-normalization">Typing,
-Filters, and Normalization</a></li>
-<li><a href="#chapter-6-values-in-memory">Values in Memory</a></li>
-<li><a href="#chapter-7-the-partial-function-abi">The Partial Function
-ABI</a></li>
-<li><a href="#chapter-8-operational-semantics-and-execution">Operational
-Semantics and Execution</a></li>
-<li><a href="#chapter-9-compiler-architecture">Compiler
-Architecture</a></li>
-<li><a href="#chapter-10-from-ast-to-intermediate-representation">From
-AST to Intermediate Representation</a></li>
-<li><a href="#chapter-11-llvm-basics">LLVM Basics</a></li>
-<li><a href="#chapter-12-code-generation">Code Generation</a></li>
-<li><a href="#chapter-13-linking-and-execution">Linking and
-Execution</a></li>
-<li><a href="#chapter-14-canonical-serialization">Canonical
-Serialization</a></li>
-<li><a href="#chapter-15-optimization-and-folding">Optimization and
-Folding</a></li>
-<li><a href="#chapter-16-toward-a-universal-schema-registry">Toward a
-Universal Schema Registry</a></li>
-</ol>
-<h2 id="appendices">Appendices</h2>
-<ul>
-<li><a
-href="#appendix-a-implementing-a-prototype-compiler-in-python">Appendix
-A: Implementing a Prototype Compiler in Python</a></li>
-<li><a
-href="#appendix-b-incorporating-external-predefined-types-and-functions">Appendix
-B: Incorporating External Predefined Types and Functions</a></li>
-</ul>
-<hr />
-<h1 id="chapter-1-introduction">Chapter 1 — Introduction</h1>
-<h2 id="the-purpose-of-this-book"><strong>1.1 The purpose of this
-book</strong></h2>
-<p>This book describes a small programming language called
-<strong>k</strong>. It is meant to show how data can be represented and
-transformed in a uniform, precise way.</p>
-<hr />
-<h2 id="data-as-trees"><strong>1.2 Data as trees</strong></h2>
-<p>All information in <code>k</code> is treated as a
-<strong>tree</strong>. A tree has:</p>
-<ul>
-<li>a single root,</li>
-<li>labeled edges (field names or tags),</li>
-<li>and possibly subtrees.</li>
-</ul>
-<p>Both JSON objects and XML documents are trees in this sense. Every
-<code>k</code> value is such a finite labeled tree.</p>
-<hr />
-<h2 id="functions-that-may-fail"><strong>1.3 Functions that may
-fail</strong></h2>
-<p>In ordinary mathematics a function always returns a result. In
-<code>k</code>, a function may be <strong>undefined</strong> for some
-inputs. For example, asking for the field <code>age</code> in a record
-that has no <code>age</code> is undefined.</p>
-<p>We call such mappings <strong>partial functions</strong>.</p>
-<hr />
-<h2 id="simplicity-over-features"><strong>1.4 Simplicity over
-features</strong></h2>
-<p><code>k</code> avoids most language constructs: no <em>variables</em>
-and no <em>control statements</em>. It has only:</p>
-<ol type="1">
-<li><strong>types</strong> (which describe tree shapes), and</li>
-<li><strong>partial functions</strong> (which transform one tree into
-another).</li>
-</ol>
-<p>These two ingredients are sufficient and powerful enough to express
-structured computation in a concise and understandable way.</p>
-<p>There is another concept in the language, called
-<strong>filters</strong>. 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 are similar to <em>type classes</em> in
-other languages.</p>
-<hr />
-<hr />
-<h1 id="chapter-2-syntax-and-values">Chapter 2 — Syntax and Values</h1>
-<h2 id="language-fragments"><strong>2.1 Language fragments</strong></h2>
-<p>The <code>k</code> language has only one kind of program element: a
-<strong>definition</strong>. A program is a sequence of definitions of
-two kinds:</p>
-<pre class="k-lang"><code>$ type_name = ...type_expression... ;
-function_name = ...expression... ;</code></pre>
-<p>The definitions are followed in the file by the <em>main
-expression</em>; it represents the partial function defined by the
-program as a whole.</p>
-<p>There is no syntax for values. Every syntactic form in an expression
-describes a <strong>function</strong> – possibly a constant function
-that always returns the same value.</p>
-<hr />
-<h2 id="types"><strong>2.2 Types</strong></h2>
-<p>A type describes the possible <strong>tree shapes</strong> of values.
-Types are formed from two constructors:</p>
-<ol type="1">
-<li><p><strong>Product</strong> – written
-<code>{ T₁ l₁, T₂ l₂, … }</code> represents records with fixed labeled
-fields.</p></li>
-<li><p><strong>Union</strong> – written
-<code>&lt; T₁ l₁, T₂ l₂, … &gt;</code> represents a choice between
-labeled alternatives.</p></li>
-</ol>
-<p>Both are finite and fully explicit. Every type denotes a finite tree
-automaton whose accepted trees are the possible values of that type.</p>
-<hr />
-<h2 id="special-and-limiting-cases"><strong>2.3 Special and limiting
-cases</strong></h2>
-<ol type="1">
-<li><p><strong>Empty product</strong> <code>{}</code> has no fields. It
-represents the type that admits exactly one value, called <em>unit</em>.
-There is nothing exceptional about the type and its value; it is simply
-the degenerate case of a product with zero fields.</p></li>
-<li><p><strong>Empty union</strong> <code>&lt;&gt;</code> has no
-variants. It represents a type with no possible values.</p></li>
-</ol>
-<hr />
-<h2 id="projections"><strong>2.4 Projections</strong></h2>
-<p><strong>Dot</strong> notation, e.g.,</p>
-<pre class="k"><code> . field_name</code></pre>
-<p>is used for extracting the value of a field from a record (product
-type value). <strong>Div</strong> notation, e.g.,</p>
-<pre class="k"><code> / variant_name</code></pre>
-<p>is used for asserting a particular variant of a union and extracting
-its value. Product type <code>{ T₁ l₁, T₂ l₂, … , Tₙ lₙ }</code>
-naturally defines <code>n</code> partial functions:
-<code>.l₁, .l₂, … , .lₙ</code>,<br />
-and union type <code>&lt; T₁ l₁, T₂ l₂, … , Tₙ lₙ &gt;</code> naturally
-defines <code>n</code> partial functions <code>/l₁, /l₂, … , /lₙ</code>.
-Those partial functions are called <strong>projections</strong> and they
-constitute the basis for the definition of all other partial functions
-in the <code>k</code> language.</p>
-<hr />
-<h2 id="functions"><strong>2.5 Functions</strong></h2>
-<p>Expressions combine partial functions using the following
-operators:</p>
-<ol type="1">
-<li><strong>Composition</strong> <code>(f₁ f₂ …)</code> — sequential
-application.</li>
-<li><strong>Union</strong> <code>&lt; f₁, f₂, … &gt;</code> — try each
-in order, first defined wins.</li>
-<li><strong>Product (parallel)</strong> <code>{ f₁ l₁, f₂ l₂, … }</code>
-— apply all to the same input, succeed only if all succeed.</li>
-<li><strong>Variant construction</strong> <code>| tag</code> — lift the
-input as a variant <code>tag</code> of a union type.</li>
-</ol>
-<p>Parentheses around a composition may be omitted except for the empty
-composition <code>()</code> — the identity function. Empty product,
-<code>{ }</code>, defines a constant function (ignoring its input)
-returning <em>unit</em>.</p>
-<p>It is important to notice that after the three markers:
-<code>dot (.)</code>, <code>div (/)</code>, or <code>pipe (|)</code>,
-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.:</p>
-<pre class="k-lang"><code>  .field /&#39;a-tag&#39; |&quot;strange and long tag name ✅&quot; </code></pre>
-<hr />
-<h2 id="example"><strong>2.6 Example</strong></h2>
-<pre class="k-lang"><code>$ bool = &lt; {} true, {} false &gt;;
-true  = {} |true $ bool;
-false = {} |false $ bool;
-neg = $ bool &lt; /true false, /false true &gt;;</code></pre>
-<p>This defines a “two-variant” union type and three functions: two
-constants and one transformation exchanging the variants.</p>
-<hr />
-<h2 id="summary"><strong>2.7 Summary</strong></h2>
-<ul>
-<li>All types describe tree shapes.</li>
-<li>As type expression, <code>{}</code> is the empty product type (with
-one value, called <em>unit</em>).</li>
-<li>Functions, not values, are the only expressions in
-<code>k</code>.</li>
-</ul>
-<hr />
-<hr />
-<h1 id="chapter-3-types-as-finite-automata">Chapter 3 — Types as Finite
-Automata</h1>
-<h2 id="motivation"><strong>3.1 Motivation</strong></h2>
-<p>A type in <code>k</code> 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.</p>
-<p>For example, the recursive type definition of a
-<code>list</code>:</p>
-<pre class="k-lang"><code>$ bool = &lt; {} true, {} false &gt;;
-$ list = &lt; {} nil, { bool head, list tail } cons &gt;;</code></pre>
-<p>corresponds to the following 4-rule grammar:</p>
-<pre class="bnf"><code>1: &lt;bool&gt; ::= {} |true
-2: &lt;bool&gt; ::= {} |false
-3: &lt;list&gt; ::= {} |nil
-4: &lt;list&gt; ::= { &lt;bool&gt; head, &lt;list&gt; tail } |cons</code></pre>
-<p>A value of type <code>list</code> is a derivation tree of this
-grammar. For instance, a list containing a single boolean value
-<code>true</code> can be represented by the following derivation:</p>
-<pre><code>&lt;list&gt;
-  -- (rule 4) --&gt; { &lt;bool&gt; head, &lt;list&gt; tail } |cons
-                     |            |
-                     |            -- (rule 3) --&gt; {} |nil
-                     |
-                     -- (rule 1) --&gt; {} |true</code></pre>
-<p>This derivation tree corresponds to the value generated by constant
-function: <code>{ {} |true head, {} |nil tail } |cons</code>.</p>
-<p>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.</p>
-<hr />
-<h2 id="states-and-transitions"><strong>3.2 States and
-Transitions</strong></h2>
-<p>Each type definition introduces one or more <em>states</em> in the
-automaton. A union or a product definition corresponds to a state, and
-the variants or fields correspond to transitions to other states.</p>
-<p>For example, consider the <code>$bool</code> type:</p>
-<pre class="k-lang"><code>$ bool = &lt; {} true, {} false &gt;;</code></pre>
-<p>This definition translates to an automaton with two states:</p>
-<ul>
-<li>A root state, let’s call it <code>C0</code>, representing the
-<code>$bool</code> type itself (a union).</li>
-<li>A state <code>C1</code> representing the empty product
-<code>{}</code>.</li>
-</ul>
-<p>From the root state <code>C0</code>, there are two transitions:</p>
-<ul>
-<li>A transition labeled <code>true</code> to state
-<code>C1</code>.</li>
-<li>A transition labeled <code>false</code> to state
-<code>C1</code>.</li>
-</ul>
-<p><code>C0</code> is the root state of the type, and <code>C1</code> is
-a leaf state, representing an empty value.</p>
-<hr />
-<h2 id="canonical-form"><strong>3.3 Canonical Form</strong></h2>
-<p>Different type expressions can describe the same automaton. For
-example:</p>
-<pre class="k-lang"><code>$ bool = &lt; {} false, {} true &gt;;
-$ pair = { bool x, bool y };
-$ pair2 = { &lt; {} true, {} false &gt; x, bool y };</code></pre>
-<p>The types <code>pair</code> and <code>pair2</code> are structurally
-equivalent because <code>$bool</code> is defined as
-<code>&lt; {} true, {} false &gt;</code>, making the definition of
-<code>x</code> in <code>pair2</code> identical to the standalone
-<code>$bool</code> type used in <code>pair</code>. Canonicalization is
-the process of removing these superficial differences by erasing local
-names and renumbering states to produce a single stable representation
-for each unique type structure.</p>
-<p>The canonical form is generated by traversing the type’s graph
-structure starting from its root state. The process ensures a unique
-representation by following a consistent ordering:</p>
-<ol type="1">
-<li><strong>Start at the Root</strong>: Assign the number
-<code>C0</code> to the root state of the type.</li>
-<li><strong>Explore Neighbors</strong>: Visit all states reachable from
-<code>C0</code>. Sort the transitions alphabetically by their labels
-(field or variant names) and assign consecutive numbers
-(<code>C1</code>, <code>C2</code>, …) to the destination states in that
-order.</li>
-<li><strong>Iterate</strong>: Move to the next state in the numbered
-sequence (<code>C1</code>, then <code>C2</code>, etc.) and repeat the
-process for any of its neighbors that have not yet been numbered.</li>
-<li><strong>Complete</strong>: Continue until all reachable states have
-been assigned a unique number.</li>
-</ol>
-<p>This traversal produces a unique and deterministic numbering for any
-finite directed graph, ensuring that any two structurally identical
-types will have the exact same canonical representation.</p>
-<hr />
-<h2 id="examples"><strong>3.4 Examples</strong></h2>
-<p>For a type representing binary natural numbers:</p>
-<pre class="k-lang"><code>$ bnat = &lt; bnat 0, bnat 1, {} _ &gt;;</code></pre>
-<p>the canonical form is:</p>
-<pre class="k-lang"><code>$C0 = &lt; C0 &quot;0&quot;, C0 &quot;1&quot;, C1 &quot;_&quot; &gt;;
-$C1 = {};</code></pre>
-<p>The automaton has two states. <code>C0</code> is a recursive state
-that recognizes sequences of “0”s and “1”s, while <code>C1</code> is the
-terminal state, marked by the “_” transition.</p>
-<hr />
-<h2 id="normalization-process"><strong>3.5 Normalization
-Process</strong></h2>
-<p>When compiling a program, the following steps are taken to normalize
-types:</p>
-<ol type="1">
-<li><strong>Collect</strong>: Gather all type definitions from the
-program.</li>
-<li><strong>Expand</strong>: Recursively replace all named types with
-their underlying definitions until only products and unions remain.</li>
-<li><strong>Deduplicate</strong>: Eliminate duplicate type structures by
-comparing them structurally.</li>
-<li><strong>Canonicalize</strong>: Assign stable state numbers to the
-unique types to produce their canonical text representation.</li>
-</ol>
-<p>This process is deterministic, ensuring that the same type structure
-always produces the exact same canonical form.</p>
-<hr />
-<h2 id="hash-based-naming"><strong>3.6 Hash-Based Naming</strong></h2>
-<p>To create a globally unique and stable identifier for each type, the
-compiler computes a hash of its canonical representation. This hash
-becomes the official, unambiguous name of the type.</p>
-<p>For example:</p>
-<pre class="text"><code>Canonical Form: $C0=&lt;C0&quot;0&quot;,C0&quot;1&quot;,C1&quot;_&quot;&gt;;$C1={}
-      ↓
-     Hash
-      ↓
-Identifier: @BsAqRMv</code></pre>
-<p>Program objects can then refer to types by their hash-based
-identifiers (prefixed with <code>@</code>) without ambiguity.</p>
-<hr />
-<h2 id="interpretation"><strong>3.7 Interpretation</strong></h2>
-<p>The canonical representation of a type can be interpreted as:</p>
-<ul>
-<li>A finite set of states, <code>C0…Cn</code>.</li>
-<li>Each state is either a product (a record with named fields) or a
-union (a set of variants).</li>
-<li>Transitions between states are labeled with strings (field or
-variant names).</li>
-</ul>
-<p>Every value of a given type is a finite tree that is accepted by this
-automaton.</p>
-<hr />
-<h2 id="summary-1"><strong>3.8 Summary</strong></h2>
-<ul>
-<li>Types in <code>k</code> denote sets of finite, labeled trees.</li>
-<li>Every type can be expressed as a finite tree automaton or a
-context-free grammar.</li>
-<li>The canonical form eliminates naming differences, providing a single
-representation for structurally identical types.</li>
-<li>Hash-based naming gives each unique type a stable and globally
-unique identifier.</li>
-</ul>
-<hr />
-<hr />
-<h1 id="chapter-4-partial-functions-and-composition">Chapter 4 — Partial
-Functions and Composition</h1>
-<h2 id="partial-functions"><strong>4.1 Partial functions</strong></h2>
-<p>A <strong>partial function</strong> is a mapping that may be
-undefined for some inputs. In <code>k</code>, every expression denotes
-such a function. If a function is undefined for a given input, the
-evaluation process halts at that point, producing no result.</p>
-<p>There is no notion of error or exception. Undefined means simply “no
-output”.</p>
-<hr />
-<h2 id="composition"><strong>4.2 Composition</strong></h2>
-<p>Composition combines two or more partial functions sequentially. If
-<code>f</code> and <code>g</code> are functions, <code>(f g)</code>
-means “apply <code>f</code>, then apply <code>g</code> to the
-result”.</p>
-<p>A composition <code>(f g)</code> is defined on a value <code>x</code>
-if and only if:</p>
-<ul>
-<li><code>f</code> is defined on <code>x</code>, and</li>
-<li><code>g</code> is defined on the result of <code>f(x)</code>.</li>
-</ul>
-<p>Otherwise, the composition is undefined.</p>
-<p>Composition is <strong>associative</strong>:</p>
-<pre class="math"><code>(f (g h))  ≡  ((f g) h)</code></pre>
-<p>Therefore, parentheses are unnecessary, except for the special case
-of the <strong>empty composition</strong>, written <code>()</code>,
-which is the identity function:</p>
-<pre class="math"><code>() x  =  x () = x</code></pre>
-<hr />
-<h2 id="product-composition"><strong>4.3 Product
-composition</strong></h2>
-<p>Product composition creates a function that applies several
-subfunctions in parallel to the same input and gathers their results
-into a product value.</p>
-<p>Syntax:</p>
-<pre class="math"><code>{ f₁ l₁, f₂ l₂, …, fₙ lₙ }</code></pre>
-<p>This expression is defined on an input value if all component
-functions are defined on that input. Its result is a product with fields
-labeled <code>l₁ … lₙ</code>, each containing the result of the
-corresponding function.</p>
-<hr />
-<h2 id="union-composition"><strong>4.4 Union composition</strong></h2>
-<p>Union composition represents concurrent evaluation with fallback:</p>
-<pre class="k-lang"><code>&lt; f₁, f₂, …, fₙ &gt;</code></pre>
-<p>The result is defined for an input <code>x</code> if at least one
-subfunction is defined. Evaluation proceeds left to right; the first
-defined result is used. If none are defined, the result is
-undefined.</p>
-<p>Example:</p>
-<pre class="k-lang"><code>&lt; /x, /y &gt;</code></pre>
-<p>extracts variant <code>x</code> if present; otherwise <code>y</code>
-if present.</p>
-<hr />
-<h2 id="constants"><strong>4.5 Constants</strong></h2>
-<p>A constant function is one that always returns the same value,
-regardless of its input. Since <code>k</code> lacks a direct syntax for
-literal values, constants are created using functions that produce
-them.</p>
-<p>For example, we can define functions that return <code>true</code>
-and <code>false</code>:</p>
-<pre class="k-lang"><code>$ bool = &lt; {} true, {} false &gt;;
-true_bool  =  {} |true $bool ;
-false_bool =  {} |false $bool ;</code></pre>
-<p>Here, <code>true_bool</code> and <code>false_bool</code> are constant
-functions. They are also <strong>total functions</strong>, meaning they
-are defined for all inputs. Each function ignores its input and produces
-a fixed boolean value.</p>
-<hr />
-<h2 id="projection-and-variant-value-constructor"><strong>4.6 Projection
-and Variant Value constructor</strong></h2>
-<p>Projection selects a field or a variant from a product or union. It
-is written with a leading dot <code>.</code> or a leading slash
-<code>/</code>, respectively:</p>
-<pre class="k-lang"><code>.x     // Selects field &#39;x&#39; from a product: { T x, ... }
-/x     // Extracts the value from a union variant &#39;x&#39;: &lt; T x, ... &gt;</code></pre>
-<p>If the input is a product, <code>.x</code> returns the value of field
-<code>x</code>. If the input is a union, <code>/x</code> returns the
-value of variant <code>x</code>. In all other cases, the projection is
-undefined.</p>
-<p>Variant value constructors for a given union type
-<code>T = &lt;T₁ tag₁, T₂ tag₂, … &gt;</code> are written as
-<code>|tag₁</code>, <code>|tag₂</code>, ….</p>
-<pre class="k-lang"><code>|tag₁    // lift a value of type T₁ into a value of type T</code></pre>
-<p>Projections and variant constructors are the most basic partial
-functions.</p>
-<hr />
-<h2 id="derived-combinations"><strong>4.7 Derived
-combinations</strong></h2>
-<p>Complex functions are built by nesting compositions. For example:</p>
-<pre class="k-lang"><code>{ .x field1, .y |tag field2 }</code></pre>
-<hr />
-<h2 id="identity-and-emptiness"><strong>4.8 Identity and
-emptiness</strong></h2>
-<p>The empty composition <code>()</code> is the identity function. The
-empty union <code>&lt;&gt;</code> is the always-undefined function. The
-empty product <code>{}</code> is the constant function returning the
-unit value.</p>
-<hr />
-<h2 id="summary-2"><strong>4.9 Summary</strong></h2>
-<ul>
-<li>In <code>k</code>, all expressions denote <strong>partial
-functions</strong>.</li>
-<li>An undefined result simply means “no output,” not an error.</li>
-<li><strong>Composition</strong> <code>(f g)</code> applies functions
-sequentially and is associative, so parentheses are often optional.</li>
-<li>The empty composition <code>()</code> is the <strong>identity
-function</strong>.</li>
-<li><strong>Product composition</strong> <code>{...}</code> runs
-functions in parallel and gathers their results.</li>
-<li><strong>Union composition</strong> <code>&lt;...&gt;</code> tries
-functions in order, returning the first successful result.</li>
-<li><strong>Projections</strong> (<code>.x</code>, <code>/x</code>) are
-fundamental building blocks for accessing data structures.</li>
-<li><strong>Variant constructor</strong> (<code>|tag</code>) allows
-lifting a value into a variant type value.</li>
-</ul>
-<hr />
-<hr />
-<h1 id="chapter-5-typing-filters-and-normalization">Chapter 5 — Typing,
-Filters, and Normalization</h1>
-<h2 id="types-as-functions"><strong>5.1 Types as functions</strong></h2>
-<p>A type expression in <code>k</code> can appear wherever a function is
-expected. When used this way, it is prefixed by <code>$</code>. It then
-behaves as a partial <strong>identity</strong> function that is defined
-only for values of that type. For example, <code>$ bool</code> is a
-partial identity: it returns its argument unchanged when the argument is
-of type <code>bool</code>, and it is undefined otherwise.</p>
-<p>This convention eliminates any special syntax for annotating
-sub-expressions with types. An expression may be <em>restricted</em> to
-a type simply by composing it with the corresponding type
-expression.</p>
-<hr />
-<h2 id="filters"><strong>5.2 Filters</strong></h2>
-<p>A <strong>filter</strong> is a syntactic form that denotes a
-<em>class of types</em> — a set of types that share a common
-structure.</p>
-<p>Filter expressions are introduced by <code>?</code> and can be:</p>
-<ul>
-<li><strong>Type expressions</strong> — <code>? $bool</code>,
-<code>? $&lt; {} x, bool y &gt;</code></li>
-<li><strong>Product filters</strong> —
-<code>? { Filter1 field1, Filter2 field2 }</code><br />
-</li>
-<li><strong>Union filters</strong> —
-<code>? &lt; Filter1 tag1, Filter2 tag2 &gt;</code></li>
-<li><strong>Product-or-union filters</strong> —
-<code>? ( Filter1 label1, Filter2 label2 )</code></li>
-<li><strong>Filter variables</strong> — <code>? X</code> (metavariables
-representing unknown types)</li>
-<li><strong>Filter bindings</strong> —
-<code>? &lt; X f, (...) = Y g, ... &gt; = X</code></li>
-</ul>
-<p>Filters may contain <code>...</code> to indicate that additional
-fields or tags are allowed: <code>? { Filter1 field1, ... }</code>
-matches any product with at least <code>field1</code>.</p>
-<p>The filter <code>? (...)</code> matches any type. The filter
-<code>? {...}</code> matches any product type. The filter
-<code>? &lt;...&gt;</code> matches any union type.</p>
-<hr />
-<h2 id="examples-of-filters"><strong>5.3 Examples of
-filters</strong></h2>
-<ul>
-<li><code>?(...)</code> — represents any type.</li>
-<li><code>?()</code> — represents an empty product or empty union.</li>
-<li><code>?&lt; (...) f, (...) g &gt;</code> — represents all union
-types having exactly two variants <code>f</code> and
-<code>g</code>.</li>
-<li><code>?{ X f, X g }</code> — represents all product types with two
-fields <code>f</code> and <code>g</code>, both of the same type.</li>
-</ul>
-<p>A filter constrains where a partial function is defined; it does not
-affect the operational behavior of the function once defined.</p>
-<hr />
-<h2 id="recursive-filters"><strong>5.4 Recursive filters</strong></h2>
-<p>Filters may be recursive. They can describe families of recursive
-types by defining a metavariable in terms of a filter that references
-it.</p>
-<p>Example (list definition):</p>
-<pre class="k-lang"><code>?&lt; {} nil, {X car, Y cdr} cons &gt; = Y</code></pre>
-<p>This filter states that <code>Y</code> is a union type with two
-variants: <code>nil</code> and <code>cons</code>.</p>
-<ul>
-<li>The <code>nil</code> variant holds an empty product
-<code>{}</code>.</li>
-<li>The <code>cons</code> variant is a product with two fields:
-<code>car</code> of some type <code>X</code>, and <code>cdr</code> of
-type <code>Y</code> itself.</li>
-</ul>
-<p>This recursive structure defines a linked list where each element has
-a <code>car</code> (the value) and a <code>cdr</code> (the rest of the
-list). It thus denotes lists of elements of type <code>X</code>.</p>
-<hr />
-<h2 id="type-variables-and-scope"><strong>5.5 Type variables and
-scope</strong></h2>
-<p>A type variable (an identifier, typically starting with an uppercase
-letter) introduced in a filter is visible within the enclosing function
-definition. For example:</p>
-<pre class="k-lang"><code>car = ?&lt; {} nil, {X car, Y cdr} cons &gt; = Y /cons .car ?X;</code></pre>
-<p>Here:</p>
-<ul>
-<li><code>X</code> and <code>Y</code> are type variables.</li>
-<li>The filter <code>?&lt;{}nil,{X car,Y cdr}cons&gt;=Y</code>
-constrains the function <code>car</code> to be defined only on types
-that match the recursive list structure.</li>
-<li>The expression <code>/cons</code> selects the <code>cons</code>
-variant of the union.</li>
-<li>The expression <code>.car</code> accesses the <code>car</code> field
-of a <code>cons</code> variant.</li>
-<li>The final filter <code>?X</code> asserts that the result of the
-field access is of type <code>X</code>, the type of the list’s
-elements.</li>
-</ul>
-<hr />
-<h2 id="type-inference-and-normalization"><strong>5.6 Type inference and
-normalization</strong></h2>
-<p>Every <code>k</code> program can be analyzed to assign an input and
-an output filter to every sub-expression. This process is called type
-inference abd normalization.</p>
-<p>Type inference and normalization proceeds as follows:</p>
-<ol type="1">
-<li>Build a graph of all type references appearing explicitly and
-implicitly in the program.</li>
-<li>Annotate each expression node with a pair of (input filter, output
-filter).</li>
-<li>Replace filters that match a single, concrete type with that type
-expression, adding any newly-discovered types to the graph.</li>
-<li>Repeat until a fixed point is reached and no more changes
-occur.</li>
-<li>Compute canonical forms for all newly introduced types.</li>
-</ol>
-<hr />
-<h2 id="summary-3"><strong>5.7 Summary</strong></h2>
-<ul>
-<li>Type expressions act as identity functions defined on values of that
-type.</li>
-<li>Filters describe sets of types and can constrain where a function is
-defined.</li>
-<li>Filters may be products, unions, or product-or-union forms, and can
-be recursive.</li>
-<li>Variables in filters have definition-level scope.</li>
-<li>Normalization computes explicit input/output filters for every
-expression.</li>
-<li>Filters are used in the normalization and type checking process.
-They are ignored at runtime.</li>
-</ul>
-<hr />
-<hr />
-<h1 id="chapter-6-values-in-memory-and-canonical-serialization">Chapter
-6 — Values in Memory and Canonical Serialization</h1>
-<h2 id="unified-value-representation"><strong>6.1 Unified value
-representation</strong></h2>
-<p>Every <code>k</code> value exists in one of three forms during
-execution:</p>
-<ol type="1">
-<li><strong>Serialized form</strong> — a canonical bit sequence that can
-be stored, transmitted, or passed between processes.</li>
-<li><strong>Lazy (or hybrid) form</strong> — a partially deserialized
-structure that keeps most data in its serialized form until access is
-needed.</li>
-<li><strong>Materialized form</strong> — a fully deserialized tree of
-nodes in memory.</li>
-</ol>
-<p>This unified approach enables programs to operate on serialized
-inputs without unnecessary deserialization, optimizing performance for
-identity operations and partial data access patterns.</p>
-<hr />
-<h2 id="the-kvalue-abstraction"><strong>6.2 The KValue
-abstraction</strong></h2>
-<p>All values are represented by a single abstraction:</p>
-<div class="sourceCode" id="cb26"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb26-1"><a href="#cb26-1" aria-hidden="true" tabindex="-1"></a><span class="kw">struct</span> KValue <span class="op">{</span></span>
-<span id="cb26-2"><a href="#cb26-2" aria-hidden="true" tabindex="-1"></a>    <span class="kw">enum</span> ValueForm <span class="op">{</span></span>
-<span id="cb26-3"><a href="#cb26-3" aria-hidden="true" tabindex="-1"></a>        SERIALIZED<span class="op">,</span>     <span class="co">// pure bitstream + type info</span></span>
-<span id="cb26-4"><a href="#cb26-4" aria-hidden="true" tabindex="-1"></a>        LAZY<span class="op">,</span>          <span class="co">// hybrid: some nodes materialized, others serialized</span></span>
-<span id="cb26-5"><a href="#cb26-5" aria-hidden="true" tabindex="-1"></a>        MATERIALIZED<span class="op">,</span>  <span class="co">// traditional tree structure</span></span>
-<span id="cb26-6"><a href="#cb26-6" aria-hidden="true" tabindex="-1"></a>        EXTERNAL       <span class="co">// built-in/foreign type with custom handlers</span></span>
-<span id="cb26-7"><a href="#cb26-7" aria-hidden="true" tabindex="-1"></a>    <span class="op">}</span> form<span class="op">;</span></span>
-<span id="cb26-8"><a href="#cb26-8" aria-hidden="true" tabindex="-1"></a>    </span>
-<span id="cb26-9"><a href="#cb26-9" aria-hidden="true" tabindex="-1"></a>    <span class="kw">union</span> <span class="op">{</span></span>
-<span id="cb26-10"><a href="#cb26-10" aria-hidden="true" tabindex="-1"></a>        <span class="kw">struct</span> <span class="op">{</span></span>
-<span id="cb26-11"><a href="#cb26-11" aria-hidden="true" tabindex="-1"></a>            <span class="dt">uint8_t</span><span class="op">*</span> bits<span class="op">;</span>          <span class="co">// canonical bitstream</span></span>
-<span id="cb26-12"><a href="#cb26-12" aria-hidden="true" tabindex="-1"></a>            <span class="dt">int</span>      type_id<span class="op">;</span>       <span class="co">// identifies canonical type</span></span>
-<span id="cb26-13"><a href="#cb26-13" aria-hidden="true" tabindex="-1"></a>        <span class="op">}</span> serialized<span class="op">;</span></span>
-<span id="cb26-14"><a href="#cb26-14" aria-hidden="true" tabindex="-1"></a>        </span>
-<span id="cb26-15"><a href="#cb26-15" aria-hidden="true" tabindex="-1"></a>        <span class="kw">struct</span> <span class="op">{</span></span>
-<span id="cb26-16"><a href="#cb26-16" aria-hidden="true" tabindex="-1"></a>            <span class="kw">struct</span> KNode<span class="op">*</span> root<span class="op">;</span>     <span class="co">// root of materialized or partially materialized tree</span></span>
-<span id="cb26-17"><a href="#cb26-17" aria-hidden="true" tabindex="-1"></a>        <span class="op">}</span> materialized<span class="op">;</span></span>
-<span id="cb26-18"><a href="#cb26-18" aria-hidden="true" tabindex="-1"></a>        </span>
-<span id="cb26-19"><a href="#cb26-19" aria-hidden="true" tabindex="-1"></a>        <span class="kw">struct</span> <span class="op">{</span></span>
-<span id="cb26-20"><a href="#cb26-20" aria-hidden="true" tabindex="-1"></a>            <span class="dt">void</span><span class="op">*</span>    data<span class="op">;</span>          <span class="co">// opaque external data</span></span>
-<span id="cb26-21"><a href="#cb26-21" aria-hidden="true" tabindex="-1"></a>            <span class="dt">int</span>      type_id<span class="op">;</span>       <span class="co">// external type identifier</span></span>
-<span id="cb26-22"><a href="#cb26-22" aria-hidden="true" tabindex="-1"></a>            ExternalOps<span class="op">*</span> ops<span class="op">;</span>       <span class="co">// function pointers for operations</span></span>
-<span id="cb26-23"><a href="#cb26-23" aria-hidden="true" tabindex="-1"></a>        <span class="op">}</span> external<span class="op">;</span></span>
-<span id="cb26-24"><a href="#cb26-24" aria-hidden="true" tabindex="-1"></a>    <span class="op">};</span></span>
-<span id="cb26-25"><a href="#cb26-25" aria-hidden="true" tabindex="-1"></a><span class="op">};</span></span></code></pre></div>
-<h3 id="self-delimiting-streams"><strong>6.2.1 Self-delimiting
-streams</strong></h3>
-<p>The canonical encoding is <strong>self-delimiting</strong>, meaning
-each value can be parsed without knowing its length in advance:</p>
-<ul>
-<li><strong>Union nodes</strong>: Fixed-length discriminators define
-clear boundaries</li>
-<li><strong>Product nodes</strong>: Type structure determines field
-count and termination<br />
-</li>
-<li><strong>External data</strong>: Length-prefixed encoding (LEB128 +
-payload)</li>
-<li><strong>Unit values</strong>: Zero bytes consumed</li>
-</ul>
-<p>This enables <strong>streaming evaluation</strong> where programs can
-process data incrementally without buffering entire inputs.</p>
-<hr />
-<h2 id="lazy-node-structure"><strong>6.3 Lazy node
-structure</strong></h2>
-<p>Nodes in lazy values can be in different states of
-materialization:</p>
-<div class="sourceCode" id="cb27"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb27-1"><a href="#cb27-1" aria-hidden="true" tabindex="-1"></a><span class="kw">struct</span> KNode <span class="op">{</span></span>
-<span id="cb27-2"><a href="#cb27-2" aria-hidden="true" tabindex="-1"></a>    <span class="dt">int</span>  state<span class="op">;</span>        <span class="co">// canonical type state (C0, C1,…)</span></span>
-<span id="cb27-3"><a href="#cb27-3" aria-hidden="true" tabindex="-1"></a>    <span class="dt">int</span>  tag<span class="op">;</span>          <span class="co">// variant index, −1 for product</span></span>
-<span id="cb27-4"><a href="#cb27-4" aria-hidden="true" tabindex="-1"></a>    <span class="dt">int</span>  arity<span class="op">;</span>        <span class="co">// number of children</span></span>
-<span id="cb27-5"><a href="#cb27-5" aria-hidden="true" tabindex="-1"></a>    </span>
-<span id="cb27-6"><a href="#cb27-6" aria-hidden="true" tabindex="-1"></a>    <span class="kw">enum</span> NodeState <span class="op">{</span></span>
-<span id="cb27-7"><a href="#cb27-7" aria-hidden="true" tabindex="-1"></a>        SERIALIZED_CHILD<span class="op">,</span>    <span class="co">// child exists as bitstream only</span></span>
-<span id="cb27-8"><a href="#cb27-8" aria-hidden="true" tabindex="-1"></a>        MATERIALIZED_CHILD<span class="op">,</span>  <span class="co">// child is fully materialized</span></span>
-<span id="cb27-9"><a href="#cb27-9" aria-hidden="true" tabindex="-1"></a>        EXTERNAL_CHILD       <span class="co">// child is external/built-in type</span></span>
-<span id="cb27-10"><a href="#cb27-10" aria-hidden="true" tabindex="-1"></a>    <span class="op">};</span></span>
-<span id="cb27-11"><a href="#cb27-11" aria-hidden="true" tabindex="-1"></a>    </span>
-<span id="cb27-12"><a href="#cb27-12" aria-hidden="true" tabindex="-1"></a>    <span class="kw">union</span> KChild <span class="op">{</span></span>
-<span id="cb27-13"><a href="#cb27-13" aria-hidden="true" tabindex="-1"></a>        <span class="kw">struct</span> <span class="op">{</span></span>
-<span id="cb27-14"><a href="#cb27-14" aria-hidden="true" tabindex="-1"></a>            <span class="kw">enum</span> NodeState state<span class="op">;</span>       <span class="co">// which kind of child this is</span></span>
-<span id="cb27-15"><a href="#cb27-15" aria-hidden="true" tabindex="-1"></a>            <span class="kw">union</span> <span class="op">{</span></span>
-<span id="cb27-16"><a href="#cb27-16" aria-hidden="true" tabindex="-1"></a>                <span class="kw">struct</span> KNode<span class="op">*</span>     node<span class="op">;</span>       <span class="co">// materialized child</span></span>
-<span id="cb27-17"><a href="#cb27-17" aria-hidden="true" tabindex="-1"></a>                <span class="kw">struct</span> <span class="op">{</span></span>
-<span id="cb27-18"><a href="#cb27-18" aria-hidden="true" tabindex="-1"></a>                    <span class="dt">uint8_t</span><span class="op">*</span>      bits<span class="op">;</span>       <span class="co">// serialized child data</span></span>
-<span id="cb27-19"><a href="#cb27-19" aria-hidden="true" tabindex="-1"></a>                    <span class="dt">int</span>           bit_offset<span class="op">;</span> <span class="co">// position within parent&#39;s bitstream</span></span>
-<span id="cb27-20"><a href="#cb27-20" aria-hidden="true" tabindex="-1"></a>                <span class="op">}</span> serialized<span class="op">;</span></span>
-<span id="cb27-21"><a href="#cb27-21" aria-hidden="true" tabindex="-1"></a>                <span class="kw">struct</span> KValue<span class="op">*</span>    external<span class="op">;</span>   <span class="co">// external child</span></span>
-<span id="cb27-22"><a href="#cb27-22" aria-hidden="true" tabindex="-1"></a>            <span class="op">};</span></span>
-<span id="cb27-23"><a href="#cb27-23" aria-hidden="true" tabindex="-1"></a>        <span class="op">};</span></span>
-<span id="cb27-24"><a href="#cb27-24" aria-hidden="true" tabindex="-1"></a>    <span class="op">}</span> child<span class="op">[];</span></span>
-<span id="cb27-25"><a href="#cb27-25" aria-hidden="true" tabindex="-1"></a><span class="op">};</span></span></code></pre></div>
-<hr />
-<h2 id="canonical-serialization-format"><strong>6.4 Canonical
-serialization format</strong></h2>
-<p>The serialized form uses a deterministic canonical encoding that
-produces identical bit sequences for structurally identical values,
-extended to support lazy evaluation:</p>
-<h3 id="canonical-encoding-principles"><strong>6.4.0 Canonical encoding
-principles</strong></h3>
-<p>The encoding is based on the canonical finite automaton
-representation of types (Chapter 3):</p>
-<h4 id="fixed-length-union-codes"><strong>Fixed-length union
-codes</strong></h4>
-<p>For each union state with <em>m</em> variants, we use
-<code>k = ceil(log2(m))</code> bits to encode the variant selection:</p>
-<table>
-<thead>
-<tr>
-<th>Variants</th>
-<th>Bits needed</th>
-<th>Example codes</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td>2</td>
-<td>1</td>
-<td><code>0</code>, <code>1</code></td>
-</tr>
-<tr>
-<td>3</td>
-<td>2</td>
-<td><code>00</code>, <code>01</code>, <code>10</code></td>
-</tr>
-<tr>
-<td>4</td>
-<td>2</td>
-<td><code>00</code>, <code>01</code>, <code>10</code>,
-<code>11</code></td>
-</tr>
-<tr>
-<td>5-8</td>
-<td>3</td>
-<td><code>000</code> through <code>111</code></td>
-</tr>
-</tbody>
-</table>
-<h4 id="encoding-by-node-type"><strong>Encoding by node
-type</strong></h4>
-<p>Each node in the value tree is encoded based on its automaton
-state:</p>
-<ul>
-<li><strong>Product nodes</strong> — emit no bits, encode children in
-canonical field order (alphabetical)</li>
-<li><strong>Union nodes</strong> — emit fixed-length variant code, then
-encode the selected child<br />
-</li>
-<li><strong>Unit nodes</strong> — emit nothing (arity = 0, no
-children)</li>
-<li><strong>External nodes</strong> — emit type marker + delegate to
-external serializer</li>
-</ul>
-<h4 id="example-natural-numbers"><strong>Example: Natural
-numbers</strong></h4>
-<p>For type <code>bnat</code>, intuitively binary natural numbers
-defined by <code>$bnat = &lt; bnat 0, bnat 1, {} _ &gt;</code>, we
-get</p>
-<pre class="k-repl"><code>--C bnat
-$ @BsAqRMv = &lt; @BsAqRMv 0, @BsAqRMv 1, @KL _ &gt;; -- $C0=&lt;C0&quot;0&quot;,C0&quot;1&quot;,C1&quot;_&quot;&gt; $C1={};</code></pre>
-<p>The corresponding Context-Free grammar is:</p>
-<pre class="text"><code>// 3 rules for C0, so we need 2 bits to encode the variant choice:
-   C0 -&gt;  C0 &quot;|0&quot;     //       encoded by &#39;00&#39;
-   C0 -&gt;  C0 &quot;|1&quot;     //       encoded by &#39;01&#39;
-   C0 -&gt;  C1 &quot;|_&quot;     //       encoded by &#39;10&#39;
-// 1 rule for C1 so we need zero bits:
-   C1 -&gt;  &#39;{}&#39;;       //       encoded by &#39;&#39;</code></pre>
-<ul>
-<li>3 variants require <code>ceil(log2(3)) = 2</code> bits</li>
-<li>Codes: <code>00</code> (0-bit), <code>01</code> (1-bit),
-<code>10</code> (end marker)</li>
-</ul>
-<p>The value <code>{}|_|0|1</code> or in JSON-like notation
-<code>{1:{0:{_:{}}}}</code> (binary 10₂ = decimal 2) encodes as:</p>
-<pre class="text"><code>01 00 10</code></pre>
-<p>This represents the left-most derivation of <code>{}|_|0|1</code>
-from <code>C0</code>.</p>
-<h4 id="prefix-free-property"><strong>Prefix-free property</strong></h4>
-<p>The encoding is <strong>prefix-free</strong>: no valid encoding is a
-prefix of another. This enables:</p>
-<ul>
-<li>Linear-time parsing without backtracking<br />
-</li>
-<li>Efficient <code>skip_field()</code> operations for lazy
-evaluation</li>
-<li>Deterministic decoding from any valid position in the stream</li>
-</ul>
-<h3 id="dag-compression-for-repeated-subtrees"><strong>6.4.1 DAG
-compression for repeated subtrees</strong></h3>
-<p>The canonical serialization can be compressed using <strong>DAG
-(Directed Acyclic Graph) representation</strong> to eliminate duplicate
-subtrees:</p>
-<h4 id="subtree-identification"><strong>Subtree
-identification</strong></h4>
-<p>Each unique subtree is assigned a <strong>node ID</strong> based on
-its canonical hash:</p>
-<pre class="text"><code>hash(node) = hash(state, tag, arity, hash(child_0), hash(child_1), ...)</code></pre>
-<p>Identical subtrees (same structure and content) get the same hash and
-share the same node ID.</p>
-<h4 id="two-pass-encoding"><strong>Two-pass encoding</strong></h4>
-<h5 id="pass-1-collection"><strong>Pass 1: Collection</strong></h5>
-<ul>
-<li>Traverse the value tree and compute hashes for all subtrees</li>
-<li>Build a <strong>node table</strong> mapping
-<code>node_id → (first_occurrence_offset, reference_count)</code></li>
-<li>Subtrees with <code>reference_count &gt; 1</code> are candidates for
-sharing</li>
-</ul>
-<h5 id="pass-2-emission"><strong>Pass 2: Emission</strong></h5>
-<ul>
-<li><strong>First occurrence</strong>: emit the full subtree
-encoding</li>
-<li><strong>Subsequent occurrences</strong>: emit a
-<strong>back-reference</strong> to the node ID</li>
-</ul>
-<h4 id="back-reference-encoding"><strong>Back-reference
-encoding</strong></h4>
-<pre class="text"><code>| Reference Bit (1) | Node ID (variable length) |</code></pre>
-<ul>
-<li><code>0</code> bit indicates normal encoding follows</li>
-<li><code>1</code> bit indicates back-reference follows</li>
-<li>Node ID uses variable-length encoding (e.g., LEB128)</li>
-</ul>
-<h4 id="example-shared-subtrees"><strong>Example: Shared
-subtrees</strong></h4>
-<p>Consider a binary tree with repeated leaf patterns:</p>
-<pre class="k-lang"><code>$tree = &lt; { tree left, tree right } branch, int leaf &gt;;</code></pre>
-<p>Value: A tree corresponding to the structure:
-<code>branch(     leaf(42),     branch(         leaf(42),         leaf(17)     ) )</code>:</p>
-<p><strong>Without DAG</strong>: Each leaf <code>(42)</code> is encoded
-separately <strong>With DAG</strong>: The <code>(42)</code> subtree is
-encoded once, then referenced</p>
-<p><strong>Encoding sequence</strong>:</p>
-<pre class="text"><code>Node Table:
-  N0: 42    (appears 2 times)
-  N1: 17    (appears 1 time)
-
-Bitstream:
-  00           // branch variant
-  0 &lt;N0&gt;       // first occurrence of value: 42
-  00           // branch variant  
-  1 N0         // back-reference to value: 42
-  0 &lt;N1&gt;       // {value: 17}</code></pre>
-<h3 id="stream-structure"><strong>6.4.2 Stream structure</strong></h3>
-<pre class="text"><code>| Header (8 bytes) | Node Count (4 bytes) | Node Table | Bitstream |</code></pre>
-<ul>
-<li><strong>Header</strong> — type hash identifying the canonical
-automaton</li>
-<li><strong>Node Count</strong> — number of shared nodes (0 = no DAG
-compression)</li>
-<li><strong>Node Table</strong> —
-<code>[node_id, offset_in_bitstream, size_in_bits]</code> for each
-shared node</li>
-<li><strong>Bitstream</strong> — concatenated prefix-free codes with
-back-references</li>
-</ul>
-<h4 id="node-table-format"><strong>Node table format</strong></h4>
-<p>When DAG compression is used (<code>Node Count &gt; 0</code>):</p>
-<pre class="text"><code>For each shared node:
-| Node ID (4 bytes) | Offset (4 bytes) | Size in bits (4 bytes) |</code></pre>
-<p>This allows the decoder to:</p>
-<ol type="1">
-<li><strong>Random access</strong>: Jump directly to any shared subtree
-definition</li>
-<li><strong>Lazy loading</strong>: Resolve back-references only when
-needed</li>
-<li><strong>Validation</strong>: Verify subtree boundaries during
-parsing</li>
-</ol>
-<h4 id="compression-algorithms"><strong>Compression
-algorithms</strong></h4>
-<p><strong>Greedy sharing</strong>: Share any subtree that appears more
-than once</p>
-<ul>
-<li>Simple to implement</li>
-<li>Good compression for naturally occurring patterns</li>
-</ul>
-<p><strong>Size-based sharing</strong>: Only share subtrees above a
-minimum size threshold</p>
-<ul>
-<li>Avoids overhead of referencing tiny subtrees</li>
-<li>Better compression ratio in practice</li>
-</ul>
-<p><strong>Frequency-weighted sharing</strong>: Prioritize subtrees by
-<code>size × frequency</code></p>
-<ul>
-<li>Optimal compression for space-constrained scenarios</li>
-<li>Requires more sophisticated analysis</li>
-</ul>
-<h4 id="lazy-back-reference-resolution"><strong>Lazy back-reference
-resolution</strong></h4>
-<p>Back-references integrate seamlessly with lazy evaluation:</p>
-<div class="sourceCode" id="cb37"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb37-1"><a href="#cb37-1" aria-hidden="true" tabindex="-1"></a>DecoratedPtr resolve_reference<span class="op">(</span>DecoratedPtr backref<span class="op">)</span> <span class="op">{</span></span>
-<span id="cb37-2"><a href="#cb37-2" aria-hidden="true" tabindex="-1"></a>    node_id <span class="op">=</span> read_variable_int<span class="op">(</span>backref<span class="op">.</span>bits<span class="op">,</span> backref<span class="op">.</span>bit_offset<span class="op">);</span></span>
-<span id="cb37-3"><a href="#cb37-3" aria-hidden="true" tabindex="-1"></a>    </span>
-<span id="cb37-4"><a href="#cb37-4" aria-hidden="true" tabindex="-1"></a>    <span class="co">// Look up in node table</span></span>
-<span id="cb37-5"><a href="#cb37-5" aria-hidden="true" tabindex="-1"></a>    node_entry <span class="op">=</span> node_table<span class="op">[</span>node_id<span class="op">];</span></span>
-<span id="cb37-6"><a href="#cb37-6" aria-hidden="true" tabindex="-1"></a>    </span>
-<span id="cb37-7"><a href="#cb37-7" aria-hidden="true" tabindex="-1"></a>    <span class="cf">return</span> <span class="op">(</span>DecoratedPtr<span class="op">)</span> <span class="op">{</span></span>
-<span id="cb37-8"><a href="#cb37-8" aria-hidden="true" tabindex="-1"></a>        <span class="op">.</span>bits <span class="op">=</span> backref<span class="op">.</span>bits<span class="op">,</span></span>
-<span id="cb37-9"><a href="#cb37-9" aria-hidden="true" tabindex="-1"></a>        <span class="op">.</span>bit_offset <span class="op">=</span> node_entry<span class="op">.</span>offset<span class="op">,</span></span>
-<span id="cb37-10"><a href="#cb37-10" aria-hidden="true" tabindex="-1"></a>        <span class="op">.</span>type_state <span class="op">=</span> node_entry<span class="op">.</span>type_state<span class="op">,</span></span>
-<span id="cb37-11"><a href="#cb37-11" aria-hidden="true" tabindex="-1"></a>        <span class="op">.</span>ref_count <span class="op">=</span> <span class="dv">1</span></span>
-<span id="cb37-12"><a href="#cb37-12" aria-hidden="true" tabindex="-1"></a>    <span class="op">};</span></span>
-<span id="cb37-13"><a href="#cb37-13" aria-hidden="true" tabindex="-1"></a><span class="op">}</span></span></code></pre></div>
-<p>The decorated pointer model naturally handles back-references as
-lightweight pointer redirections.</p>
-<h4 id="memory-vs.-compression-trade-offs"><strong>Memory
-vs. compression trade-offs</strong></h4>
-<table>
-<thead>
-<tr>
-<th>Strategy</th>
-<th>Memory usage</th>
-<th>Compression ratio</th>
-<th>Decode speed</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td>No DAG</td>
-<td>Low</td>
-<td>1.0× (baseline)</td>
-<td>Fastest</td>
-</tr>
-<tr>
-<td>Greedy DAG</td>
-<td>Medium</td>
-<td>2-10×</td>
-<td>Fast</td>
-</tr>
-<tr>
-<td>Optimal DAG</td>
-<td>High</td>
-<td>5-50×</td>
-<td>Medium</td>
-</tr>
-</tbody>
-</table>
-<p>For <strong>streaming applications</strong>: Prefer greedy DAG with
-small node tables For <strong>archival storage</strong>: Use optimal DAG
-compression For <strong>real-time processing</strong>: Skip DAG
-compression entirely</p>
-<h4
-id="compression-example-repeated-data-structures"><strong>Compression
-example: Repeated data structures</strong></h4>
-<p>Consider a list of similar records:</p>
-<pre class="k-lang"><code>$record = { string name, int age, string department };
-$company = &lt; { record head, company tail } cons, {} nil &gt;;</code></pre>
-<p>Value representing 1000 employees where 80% work in
-“Engineering”:</p>
-<pre class="text"><code>Without DAG: Each &quot;Engineering&quot; string encoded separately
-- 1000 records × 30 bytes/record = 30KB
-
-With DAG: &quot;Engineering&quot; string shared via back-references  
-- 1 × &quot;Engineering&quot; (11 bytes) + 800 × back-reference (3 bytes) = 2.4KB
-- Compression ratio: ~12.5×</code></pre>
-<p>The DAG representation transforms the <strong>tree</strong> into a
-more efficient <strong>directed acyclic graph</strong>:</p>
-<pre class="text"><code>Tree:     Record1 → &quot;Engineering&quot;
-          Record2 → &quot;Engineering&quot;  
-          Record3 → &quot;Engineering&quot;
-          ...
-
-DAG:      Record1 ↘
-          Record2 → Shared(&quot;Engineering&quot;)
-          Record3 ↗
-          ...</code></pre>
-<h3 id="hardware-optimized-encoding"><strong>6.4.3 Hardware-optimized
-encoding</strong></h3>
-<p>While bit-level precision is theoretically optimal, modern hardware
-operates on <strong>byte-aligned data</strong> using <strong>word-sized
-registers</strong>. A practical encoding must balance compression with
-decode performance.</p>
-<h4 id="register-friendly-union-encoding"><strong>Register-friendly
-union encoding</strong></h4>
-<p>Instead of <code>ceil(log2(m))</code> bits, use <strong>byte-aligned
-codes</strong> optimized for common union sizes:</p>
-<table>
-<thead>
-<tr>
-<th>Union variants</th>
-<th>Theoretical bits</th>
-<th>Hardware-optimized</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td>2-3 variants</td>
-<td>1-2 bits</td>
-<td>1 byte (8 bits)</td>
-</tr>
-<tr>
-<td>4-15 variants</td>
-<td>2-4 bits</td>
-<td>1 byte (8 bits)</td>
-</tr>
-<tr>
-<td>16-255 variants</td>
-<td>4-8 bits</td>
-<td>1 byte (8 bits)</td>
-</tr>
-<tr>
-<td>256+ variants</td>
-<td>8+ bits</td>
-<td>2+ bytes (LEB128)</td>
-</tr>
-</tbody>
-</table>
-<p><strong>Rationale</strong>: Single-byte discriminators enable
-efficient decoding with simple memory loads and bit masking.</p>
-<h4 id="simd-friendly-data-layout"><strong>SIMD-friendly data
-layout</strong></h4>
-<p>Modern CPUs can process multiple bytes simultaneously using
-<strong>SIMD instructions</strong>. Structure the encoding to leverage
-this:</p>
-<div class="sourceCode" id="cb41"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb41-1"><a href="#cb41-1" aria-hidden="true" tabindex="-1"></a><span class="co">// Bad: bit-packed discriminators</span></span>
-<span id="cb41-2"><a href="#cb41-2" aria-hidden="true" tabindex="-1"></a><span class="kw">struct</span> BitPacked <span class="op">{</span></span>
-<span id="cb41-3"><a href="#cb41-3" aria-hidden="true" tabindex="-1"></a>    <span class="dt">uint64_t</span> discriminators<span class="op">;</span>  <span class="co">// 8 × 8-bit = 64 discriminators packed</span></span>
-<span id="cb41-4"><a href="#cb41-4" aria-hidden="true" tabindex="-1"></a>    <span class="co">// Requires expensive bit extraction</span></span>
-<span id="cb41-5"><a href="#cb41-5" aria-hidden="true" tabindex="-1"></a><span class="op">};</span></span>
-<span id="cb41-6"><a href="#cb41-6" aria-hidden="true" tabindex="-1"></a></span>
-<span id="cb41-7"><a href="#cb41-7" aria-hidden="true" tabindex="-1"></a><span class="co">// Good: byte-aligned discriminators  </span></span>
-<span id="cb41-8"><a href="#cb41-8" aria-hidden="true" tabindex="-1"></a><span class="kw">struct</span> ByteAligned <span class="op">{</span></span>
-<span id="cb41-9"><a href="#cb41-9" aria-hidden="true" tabindex="-1"></a>    <span class="dt">uint8_t</span> discriminators<span class="op">[</span><span class="dv">8</span><span class="op">];</span>  <span class="co">// 8 discriminators, SIMD-friendly</span></span>
-<span id="cb41-10"><a href="#cb41-10" aria-hidden="true" tabindex="-1"></a>    <span class="co">// Can be processed with single AVX2 instruction</span></span>
-<span id="cb41-11"><a href="#cb41-11" aria-hidden="true" tabindex="-1"></a><span class="op">};</span></span></code></pre></div>
-<h4 id="cache-line-aware-field-ordering"><strong>Cache-line aware field
-ordering</strong></h4>
-<p>Arrange product fields to minimize <strong>cache misses</strong>:</p>
-<div class="sourceCode" id="cb42"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb42-1"><a href="#cb42-1" aria-hidden="true" tabindex="-1"></a><span class="co">// Product field layout optimization</span></span>
-<span id="cb42-2"><a href="#cb42-2" aria-hidden="true" tabindex="-1"></a><span class="kw">struct</span> ProductLayout <span class="op">{</span></span>
-<span id="cb42-3"><a href="#cb42-3" aria-hidden="true" tabindex="-1"></a>    <span class="dt">uint8_t</span>  discriminators<span class="op">[</span>N<span class="op">];</span>     <span class="co">// All discriminators together (hot data)</span></span>
-<span id="cb42-4"><a href="#cb42-4" aria-hidden="true" tabindex="-1"></a>    <span class="dt">uint8_t</span>  padding<span class="op">[</span><span class="dv">64</span> <span class="op">-</span> N <span class="op">%</span> <span class="dv">64</span><span class="op">];</span>  <span class="co">// Align to cache line boundary</span></span>
-<span id="cb42-5"><a href="#cb42-5" aria-hidden="true" tabindex="-1"></a>    <span class="dt">uint8_t</span>  field_data<span class="op">[];</span>          <span class="co">// Field data follows (cold data)</span></span>
-<span id="cb42-6"><a href="#cb42-6" aria-hidden="true" tabindex="-1"></a><span class="op">};</span></span></code></pre></div>
-<p>Fields are ordered by <strong>access frequency</strong> rather than
-alphabetical order:</p>
-<ul>
-<li><strong>Hot fields</strong> (frequently accessed): placed
-first<br />
-</li>
-<li><strong>Cold fields</strong> (rarely accessed): placed last</li>
-<li><strong>Large fields</strong> (arrays, strings): placed at end to
-avoid cache pollution</li>
-</ul>
-<h4 id="word-aligned-pointer-arithmetic"><strong>Word-aligned pointer
-arithmetic</strong></h4>
-<p>Replace bit-level navigation with <strong>word-aligned
-operations</strong>:</p>
-<div class="sourceCode" id="cb43"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb43-1"><a href="#cb43-1" aria-hidden="true" tabindex="-1"></a><span class="co">// Bit-level navigation (slow)</span></span>
-<span id="cb43-2"><a href="#cb43-2" aria-hidden="true" tabindex="-1"></a>DecoratedPtr navigate_bitwise<span class="op">(</span>DecoratedPtr ptr<span class="op">,</span> <span class="dt">int</span> field_index<span class="op">)</span> <span class="op">{</span></span>
-<span id="cb43-3"><a href="#cb43-3" aria-hidden="true" tabindex="-1"></a>    <span class="dt">size_t</span> bit_offset <span class="op">=</span> ptr<span class="op">.</span>bit_offset<span class="op">;</span></span>
-<span id="cb43-4"><a href="#cb43-4" aria-hidden="true" tabindex="-1"></a>    <span class="cf">for</span> <span class="op">(</span><span class="dt">int</span> i <span class="op">=</span> <span class="dv">0</span><span class="op">;</span> i <span class="op">&lt;</span> field_index<span class="op">;</span> i<span class="op">++)</span> <span class="op">{</span></span>
-<span id="cb43-5"><a href="#cb43-5" aria-hidden="true" tabindex="-1"></a>        bit_offset <span class="op">+=</span> extract_field_bit_size<span class="op">(</span>ptr<span class="op">.</span>bits<span class="op">,</span> bit_offset<span class="op">);</span>  <span class="co">// Expensive!</span></span>
-<span id="cb43-6"><a href="#cb43-6" aria-hidden="true" tabindex="-1"></a>    <span class="op">}</span></span>
-<span id="cb43-7"><a href="#cb43-7" aria-hidden="true" tabindex="-1"></a>    <span class="cf">return</span> make_ptr<span class="op">(</span>ptr<span class="op">.</span>bits<span class="op">,</span> bit_offset<span class="op">);</span></span>
-<span id="cb43-8"><a href="#cb43-8" aria-hidden="true" tabindex="-1"></a><span class="op">}</span></span>
-<span id="cb43-9"><a href="#cb43-9" aria-hidden="true" tabindex="-1"></a></span>
-<span id="cb43-10"><a href="#cb43-10" aria-hidden="true" tabindex="-1"></a><span class="co">// Word-aligned navigation (fast)</span></span>
-<span id="cb43-11"><a href="#cb43-11" aria-hidden="true" tabindex="-1"></a>DecoratedPtr navigate_wordwise<span class="op">(</span>DecoratedPtr ptr<span class="op">,</span> <span class="dt">int</span> field_index<span class="op">)</span> <span class="op">{</span></span>
-<span id="cb43-12"><a href="#cb43-12" aria-hidden="true" tabindex="-1"></a>    <span class="dt">uint8_t</span><span class="op">*</span> byte_ptr <span class="op">=</span> ptr<span class="op">.</span>bits <span class="op">+</span> <span class="op">(</span>ptr<span class="op">.</span>bit_offset <span class="op">&gt;&gt;</span> <span class="dv">3</span><span class="op">);</span>  <span class="co">// Convert to byte offset</span></span>
-<span id="cb43-13"><a href="#cb43-13" aria-hidden="true" tabindex="-1"></a>    </span>
-<span id="cb43-14"><a href="#cb43-14" aria-hidden="true" tabindex="-1"></a>    <span class="co">// Read field offset table (precomputed during encoding)</span></span>
-<span id="cb43-15"><a href="#cb43-15" aria-hidden="true" tabindex="-1"></a>    <span class="dt">uint32_t</span><span class="op">*</span> offset_table <span class="op">=</span> <span class="op">(</span><span class="dt">uint32_t</span><span class="op">*)</span>byte_ptr<span class="op">;</span></span>
-<span id="cb43-16"><a href="#cb43-16" aria-hidden="true" tabindex="-1"></a>    <span class="dt">uint32_t</span> field_offset <span class="op">=</span> offset_table<span class="op">[</span>field_index<span class="op">];</span>     <span class="co">// Single memory load</span></span>
-<span id="cb43-17"><a href="#cb43-17" aria-hidden="true" tabindex="-1"></a>    </span>
-<span id="cb43-18"><a href="#cb43-18" aria-hidden="true" tabindex="-1"></a>    <span class="cf">return</span> make_ptr<span class="op">(</span>ptr<span class="op">.</span>bits<span class="op">,</span> field_offset <span class="op">&lt;&lt;</span> <span class="dv">3</span><span class="op">);</span>         <span class="co">// Convert back to bits</span></span>
-<span id="cb43-19"><a href="#cb43-19" aria-hidden="true" tabindex="-1"></a><span class="op">}</span></span></code></pre></div>
-<h4 id="cpu-instruction-optimization"><strong>CPU instruction
-optimization</strong></h4>
-<p><strong>Branch prediction friendly encoding</strong>:</p>
-<div class="sourceCode" id="cb44"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb44-1"><a href="#cb44-1" aria-hidden="true" tabindex="-1"></a><span class="co">// Bad: unpredictable branching</span></span>
-<span id="cb44-2"><a href="#cb44-2" aria-hidden="true" tabindex="-1"></a><span class="dt">uint8_t</span> discriminator <span class="op">=</span> <span class="op">*</span>byte_ptr<span class="op">++;</span></span>
-<span id="cb44-3"><a href="#cb44-3" aria-hidden="true" tabindex="-1"></a><span class="cf">switch</span> <span class="op">(</span>discriminator<span class="op">)</span> <span class="op">{</span></span>
-<span id="cb44-4"><a href="#cb44-4" aria-hidden="true" tabindex="-1"></a>    <span class="cf">case</span> <span class="dv">0</span><span class="op">:</span> handle_variant_0<span class="op">();</span> <span class="cf">break</span><span class="op">;</span></span>
-<span id="cb44-5"><a href="#cb44-5" aria-hidden="true" tabindex="-1"></a>    <span class="cf">case</span> <span class="dv">1</span><span class="op">:</span> handle_variant_1<span class="op">();</span> <span class="cf">break</span><span class="op">;</span></span>
-<span id="cb44-6"><a href="#cb44-6" aria-hidden="true" tabindex="-1"></a>    <span class="cf">case</span> <span class="dv">2</span><span class="op">:</span> handle_variant_2<span class="op">();</span> <span class="cf">break</span><span class="op">;</span></span>
-<span id="cb44-7"><a href="#cb44-7" aria-hidden="true" tabindex="-1"></a>    <span class="co">// ... many cases cause branch misprediction</span></span>
-<span id="cb44-8"><a href="#cb44-8" aria-hidden="true" tabindex="-1"></a><span class="op">}</span></span>
-<span id="cb44-9"><a href="#cb44-9" aria-hidden="true" tabindex="-1"></a></span>
-<span id="cb44-10"><a href="#cb44-10" aria-hidden="true" tabindex="-1"></a><span class="co">// Good: function table dispatch</span></span>
-<span id="cb44-11"><a href="#cb44-11" aria-hidden="true" tabindex="-1"></a><span class="kw">typedef</span> <span class="dt">void</span> <span class="op">(*</span>VariantHandler<span class="op">)(</span><span class="dt">uint8_t</span><span class="op">*</span> data<span class="op">);</span></span>
-<span id="cb44-12"><a href="#cb44-12" aria-hidden="true" tabindex="-1"></a><span class="dt">static</span> VariantHandler variant_handlers<span class="op">[</span><span class="dv">256</span><span class="op">]</span> <span class="op">=</span> <span class="op">{</span></span>
-<span id="cb44-13"><a href="#cb44-13" aria-hidden="true" tabindex="-1"></a>    handle_variant_0<span class="op">,</span> handle_variant_1<span class="op">,</span> handle_variant_2<span class="op">,</span> <span class="co">/* ... */</span></span>
-<span id="cb44-14"><a href="#cb44-14" aria-hidden="true" tabindex="-1"></a><span class="op">};</span></span>
-<span id="cb44-15"><a href="#cb44-15" aria-hidden="true" tabindex="-1"></a></span>
-<span id="cb44-16"><a href="#cb44-16" aria-hidden="true" tabindex="-1"></a><span class="dt">uint8_t</span> discriminator <span class="op">=</span> <span class="op">*</span>byte_ptr<span class="op">++;</span></span>
-<span id="cb44-17"><a href="#cb44-17" aria-hidden="true" tabindex="-1"></a>variant_handlers<span class="op">[</span>discriminator<span class="op">](</span>byte_ptr<span class="op">);</span>  <span class="co">// Single indirect call</span></span></code></pre></div>
-<p><strong>Prefetch-aware access patterns</strong>:</p>
-<div class="sourceCode" id="cb45"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb45-1"><a href="#cb45-1" aria-hidden="true" tabindex="-1"></a><span class="co">// Sequential prefetching for product fields</span></span>
-<span id="cb45-2"><a href="#cb45-2" aria-hidden="true" tabindex="-1"></a><span class="dt">void</span> prefetch_product_fields<span class="op">(</span>DecoratedPtr ptr<span class="op">,</span> <span class="dt">int</span> num_fields<span class="op">)</span> <span class="op">{</span></span>
-<span id="cb45-3"><a href="#cb45-3" aria-hidden="true" tabindex="-1"></a>    <span class="dt">uint32_t</span><span class="op">*</span> offset_table <span class="op">=</span> <span class="op">(</span><span class="dt">uint32_t</span><span class="op">*)(</span>ptr<span class="op">.</span>bits <span class="op">+</span> <span class="op">(</span>ptr<span class="op">.</span>bit_offset <span class="op">&gt;&gt;</span> <span class="dv">3</span><span class="op">));</span></span>
-<span id="cb45-4"><a href="#cb45-4" aria-hidden="true" tabindex="-1"></a>    </span>
-<span id="cb45-5"><a href="#cb45-5" aria-hidden="true" tabindex="-1"></a>    <span class="co">// Prefetch offset table into L1 cache</span></span>
-<span id="cb45-6"><a href="#cb45-6" aria-hidden="true" tabindex="-1"></a>    __builtin_prefetch<span class="op">(</span>offset_table<span class="op">,</span> <span class="dv">0</span><span class="op">,</span> <span class="dv">3</span><span class="op">);</span>  <span class="co">// Read, high temporal locality</span></span>
-<span id="cb45-7"><a href="#cb45-7" aria-hidden="true" tabindex="-1"></a>    </span>
-<span id="cb45-8"><a href="#cb45-8" aria-hidden="true" tabindex="-1"></a>    <span class="co">// Prefetch first few fields</span></span>
-<span id="cb45-9"><a href="#cb45-9" aria-hidden="true" tabindex="-1"></a>    <span class="cf">for</span> <span class="op">(</span><span class="dt">int</span> i <span class="op">=</span> <span class="dv">0</span><span class="op">;</span> i <span class="op">&lt;</span> min<span class="op">(</span>num_fields<span class="op">,</span> <span class="dv">4</span><span class="op">);</span> i<span class="op">++)</span> <span class="op">{</span></span>
-<span id="cb45-10"><a href="#cb45-10" aria-hidden="true" tabindex="-1"></a>        <span class="dt">uint8_t</span><span class="op">*</span> field_ptr <span class="op">=</span> ptr<span class="op">.</span>bits <span class="op">+</span> offset_table<span class="op">[</span>i<span class="op">];</span></span>
-<span id="cb45-11"><a href="#cb45-11" aria-hidden="true" tabindex="-1"></a>        __builtin_prefetch<span class="op">(</span>field_ptr<span class="op">,</span> <span class="dv">0</span><span class="op">,</span> <span class="dv">2</span><span class="op">);</span>  <span class="co">// Read, medium temporal locality</span></span>
-<span id="cb45-12"><a href="#cb45-12" aria-hidden="true" tabindex="-1"></a>    <span class="op">}</span></span>
-<span id="cb45-13"><a href="#cb45-13" aria-hidden="true" tabindex="-1"></a><span class="op">}</span></span></code></pre></div>
-<h4 id="memory-bandwidth-optimization"><strong>Memory bandwidth
-optimization</strong></h4>
-<p><strong>Streaming-friendly encoding</strong>:</p>
-<div class="sourceCode" id="cb46"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb46-1"><a href="#cb46-1" aria-hidden="true" tabindex="-1"></a><span class="co">// Structure data for optimal memory bandwidth</span></span>
-<span id="cb46-2"><a href="#cb46-2" aria-hidden="true" tabindex="-1"></a><span class="kw">struct</span> StreamLayout <span class="op">{</span></span>
-<span id="cb46-3"><a href="#cb46-3" aria-hidden="true" tabindex="-1"></a>    <span class="kw">struct</span> <span class="op">{</span></span>
-<span id="cb46-4"><a href="#cb46-4" aria-hidden="true" tabindex="-1"></a>        <span class="dt">uint32_t</span> total_size<span class="op">;</span>        <span class="co">// 4 bytes</span></span>
-<span id="cb46-5"><a href="#cb46-5" aria-hidden="true" tabindex="-1"></a>        <span class="dt">uint16_t</span> num_fields<span class="op">;</span>        <span class="co">// 2 bytes  </span></span>
-<span id="cb46-6"><a href="#cb46-6" aria-hidden="true" tabindex="-1"></a>        <span class="dt">uint16_t</span> flags<span class="op">;</span>             <span class="co">// 2 bytes (padding + metadata)</span></span>
-<span id="cb46-7"><a href="#cb46-7" aria-hidden="true" tabindex="-1"></a>    <span class="op">}</span> header<span class="op">;</span>                       <span class="co">// 8 bytes total (fits in single cache line)</span></span>
-<span id="cb46-8"><a href="#cb46-8" aria-hidden="true" tabindex="-1"></a>    </span>
-<span id="cb46-9"><a href="#cb46-9" aria-hidden="true" tabindex="-1"></a>    <span class="dt">uint32_t</span> field_offsets<span class="op">[];</span>       <span class="co">// 4N bytes (word-aligned)</span></span>
-<span id="cb46-10"><a href="#cb46-10" aria-hidden="true" tabindex="-1"></a>    <span class="dt">uint8_t</span>  field_data<span class="op">[];</span>          <span class="co">// Variable length data</span></span>
-<span id="cb46-11"><a href="#cb46-11" aria-hidden="true" tabindex="-1"></a><span class="op">};</span></span></code></pre></div>
-<p><strong>Memory access patterns</strong>:</p>
-<ul>
-<li><strong>Sequential reads</strong>: Optimal for streaming
-workloads</li>
-<li><strong>Random access</strong>: Offset table enables O(1) field
-access</li>
-<li><strong>Bulk operations</strong>: SIMD can process multiple
-discriminators simultaneously</li>
-</ul>
-<h4 id="hardware-specific-optimizations"><strong>Hardware-specific
-optimizations</strong></h4>
-<p><strong>x86-64 optimizations</strong>:</p>
-<div class="sourceCode" id="cb47"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb47-1"><a href="#cb47-1" aria-hidden="true" tabindex="-1"></a><span class="co">// Exploit x86-64 addressing modes</span></span>
-<span id="cb47-2"><a href="#cb47-2" aria-hidden="true" tabindex="-1"></a>DecoratedPtr navigate_x86<span class="op">(</span>DecoratedPtr ptr<span class="op">,</span> <span class="dt">int</span> field_index<span class="op">)</span> <span class="op">{</span></span>
-<span id="cb47-3"><a href="#cb47-3" aria-hidden="true" tabindex="-1"></a>    <span class="dt">uint32_t</span><span class="op">*</span> offset_table <span class="op">=</span> <span class="op">(</span><span class="dt">uint32_t</span><span class="op">*)(</span>ptr<span class="op">.</span>bits <span class="op">+</span> <span class="op">(</span>ptr<span class="op">.</span>bit_offset <span class="op">&gt;&gt;</span> <span class="dv">3</span><span class="op">));</span></span>
-<span id="cb47-4"><a href="#cb47-4" aria-hidden="true" tabindex="-1"></a>    </span>
-<span id="cb47-5"><a href="#cb47-5" aria-hidden="true" tabindex="-1"></a>    <span class="co">// Single instruction: LEA + memory operand</span></span>
-<span id="cb47-6"><a href="#cb47-6" aria-hidden="true" tabindex="-1"></a>    <span class="dt">uint8_t</span><span class="op">*</span> field_ptr <span class="op">=</span> ptr<span class="op">.</span>bits <span class="op">+</span> offset_table<span class="op">[</span>field_index<span class="op">];</span></span>
-<span id="cb47-7"><a href="#cb47-7" aria-hidden="true" tabindex="-1"></a>    </span>
-<span id="cb47-8"><a href="#cb47-8" aria-hidden="true" tabindex="-1"></a>    <span class="cf">return</span> make_ptr_from_bytes<span class="op">(</span>field_ptr<span class="op">);</span></span>
-<span id="cb47-9"><a href="#cb47-9" aria-hidden="true" tabindex="-1"></a><span class="op">}</span></span>
-<span id="cb47-10"><a href="#cb47-10" aria-hidden="true" tabindex="-1"></a></span>
-<span id="cb47-11"><a href="#cb47-11" aria-hidden="true" tabindex="-1"></a><span class="co">// Utilize SIMD for bulk discriminator reading</span></span>
-<span id="cb47-12"><a href="#cb47-12" aria-hidden="true" tabindex="-1"></a><span class="dt">void</span> decode_discriminators_avx2<span class="op">(</span><span class="dt">uint8_t</span><span class="op">*</span> input<span class="op">,</span> <span class="dt">uint8_t</span><span class="op">*</span> output<span class="op">,</span> <span class="dt">size_t</span> count<span class="op">)</span> <span class="op">{</span></span>
-<span id="cb47-13"><a href="#cb47-13" aria-hidden="true" tabindex="-1"></a>    __m256i<span class="op">*</span> input_vec <span class="op">=</span> <span class="op">(</span>__m256i<span class="op">*)</span>input<span class="op">;</span></span>
-<span id="cb47-14"><a href="#cb47-14" aria-hidden="true" tabindex="-1"></a>    __m256i<span class="op">*</span> output_vec <span class="op">=</span> <span class="op">(</span>__m256i<span class="op">*)</span>output<span class="op">;</span></span>
-<span id="cb47-15"><a href="#cb47-15" aria-hidden="true" tabindex="-1"></a>    </span>
-<span id="cb47-16"><a href="#cb47-16" aria-hidden="true" tabindex="-1"></a>    <span class="cf">for</span> <span class="op">(</span><span class="dt">size_t</span> i <span class="op">=</span> <span class="dv">0</span><span class="op">;</span> i <span class="op">&lt;</span> count <span class="op">/</span> <span class="dv">32</span><span class="op">;</span> i<span class="op">++)</span> <span class="op">{</span></span>
-<span id="cb47-17"><a href="#cb47-17" aria-hidden="true" tabindex="-1"></a>        __m256i data <span class="op">=</span> _mm256_load_si256<span class="op">(&amp;</span>input_vec<span class="op">[</span>i<span class="op">]);</span></span>
-<span id="cb47-18"><a href="#cb47-18" aria-hidden="true" tabindex="-1"></a>        </span>
-<span id="cb47-19"><a href="#cb47-19" aria-hidden="true" tabindex="-1"></a>        <span class="co">// Process 32 discriminators in parallel</span></span>
-<span id="cb47-20"><a href="#cb47-20" aria-hidden="true" tabindex="-1"></a>        __m256i decoded <span class="op">=</span> _mm256_and_si256<span class="op">(</span>data<span class="op">,</span> _mm256_set1_epi8<span class="op">(</span><span class="bn">0x0F</span><span class="op">));</span></span>
-<span id="cb47-21"><a href="#cb47-21" aria-hidden="true" tabindex="-1"></a>        </span>
-<span id="cb47-22"><a href="#cb47-22" aria-hidden="true" tabindex="-1"></a>        _mm256_store_si256<span class="op">(&amp;</span>output_vec<span class="op">[</span>i<span class="op">],</span> decoded<span class="op">);</span></span>
-<span id="cb47-23"><a href="#cb47-23" aria-hidden="true" tabindex="-1"></a>    <span class="op">}</span></span>
-<span id="cb47-24"><a href="#cb47-24" aria-hidden="true" tabindex="-1"></a><span class="op">}</span></span></code></pre></div>
-<p><strong>ARM64 optimizations</strong>:</p>
-<div class="sourceCode" id="cb48"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb48-1"><a href="#cb48-1" aria-hidden="true" tabindex="-1"></a><span class="co">// Exploit ARM64 load-with-offset instructions</span></span>
-<span id="cb48-2"><a href="#cb48-2" aria-hidden="true" tabindex="-1"></a>DecoratedPtr navigate_arm64<span class="op">(</span>DecoratedPtr ptr<span class="op">,</span> <span class="dt">int</span> field_index<span class="op">)</span> <span class="op">{</span></span>
-<span id="cb48-3"><a href="#cb48-3" aria-hidden="true" tabindex="-1"></a>    <span class="dt">uint32_t</span><span class="op">*</span> offset_table <span class="op">=</span> <span class="op">(</span><span class="dt">uint32_t</span><span class="op">*)(</span>ptr<span class="op">.</span>bits <span class="op">+</span> <span class="op">(</span>ptr<span class="op">.</span>bit_offset <span class="op">&gt;&gt;</span> <span class="dv">3</span><span class="op">));</span></span>
-<span id="cb48-4"><a href="#cb48-4" aria-hidden="true" tabindex="-1"></a>    </span>
-<span id="cb48-5"><a href="#cb48-5" aria-hidden="true" tabindex="-1"></a>    <span class="co">// ARM64: single LDR instruction with register offset</span></span>
-<span id="cb48-6"><a href="#cb48-6" aria-hidden="true" tabindex="-1"></a>    <span class="dt">uint32_t</span> offset <span class="op">=</span> offset_table<span class="op">[</span>field_index<span class="op">];</span></span>
-<span id="cb48-7"><a href="#cb48-7" aria-hidden="true" tabindex="-1"></a>    <span class="dt">uint8_t</span><span class="op">*</span> field_ptr <span class="op">=</span> ptr<span class="op">.</span>bits <span class="op">+</span> offset<span class="op">;</span></span>
-<span id="cb48-8"><a href="#cb48-8" aria-hidden="true" tabindex="-1"></a>    </span>
-<span id="cb48-9"><a href="#cb48-9" aria-hidden="true" tabindex="-1"></a>    <span class="cf">return</span> make_ptr_from_bytes<span class="op">(</span>field_ptr<span class="op">);</span></span>
-<span id="cb48-10"><a href="#cb48-10" aria-hidden="true" tabindex="-1"></a><span class="op">}</span></span></code></pre></div>
-<h4
-id="performance-analysis-hardware-vs.-theoretical-encoding"><strong>Performance
-analysis: Hardware vs. theoretical encoding</strong></h4>
-<p><strong>Decoding performance comparison</strong> (cycles per field
-access):</p>
-<table>
-<colgroup>
-<col style="width: 27%" />
-<col style="width: 27%" />
-<col style="width: 23%" />
-<col style="width: 20%" />
-</colgroup>
-<thead>
-<tr>
-<th>Encoding strategy</th>
-<th>Field access cost</th>
-<th>Cache behavior</th>
-<th>SIMD support</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td>Bit-packed optimal</td>
-<td>50-100 cycles</td>
-<td>Poor (bit manipulation)</td>
-<td>No</td>
-</tr>
-<tr>
-<td>Byte-aligned</td>
-<td>5-15 cycles</td>
-<td>Good (word loads)</td>
-<td>Yes</td>
-</tr>
-<tr>
-<td>Word-aligned + offset table</td>
-<td>2-8 cycles</td>
-<td>Excellent (prefetchable)</td>
-<td>Yes</td>
-</tr>
-</tbody>
-</table>
-<p><strong>Space vs. time trade-offs</strong>:</p>
-<pre><code>Bit-packed:     100% space efficiency, 10× decode overhead
-Byte-aligned:   90% space efficiency,   2× decode overhead  
-Word-aligned:   80% space efficiency,   1× decode overhead (baseline)</code></pre>
-<p><strong>Real-world measurements</strong> (modern x86-64, 3.2GHz):</p>
-<div class="sourceCode" id="cb50"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb50-1"><a href="#cb50-1" aria-hidden="true" tabindex="-1"></a><span class="co">// Benchmark: Navigate to field in 1000-field product</span></span>
-<span id="cb50-2"><a href="#cb50-2" aria-hidden="true" tabindex="-1"></a>Bit<span class="op">-</span>manipulation<span class="op">:</span>     <span class="dv">2</span><span class="op">,</span><span class="dv">400</span> ns  <span class="op">(</span><span class="dv">7</span><span class="op">,</span><span class="dv">680</span> cycles<span class="op">)</span></span>
-<span id="cb50-3"><a href="#cb50-3" aria-hidden="true" tabindex="-1"></a>Byte<span class="op">-</span>aligned<span class="op">:</span>           <span class="dv">480</span> ns  <span class="op">(</span><span class="dv">1</span><span class="op">,</span><span class="dv">536</span> cycles<span class="op">)</span>  </span>
-<span id="cb50-4"><a href="#cb50-4" aria-hidden="true" tabindex="-1"></a>Word<span class="op">-</span>aligned table<span class="op">:</span>     <span class="dv">160</span> ns    <span class="op">(</span><span class="dv">512</span> cycles<span class="op">)</span></span></code></pre></div>
-<p>The <strong>offset table approach</strong> provides the best
-practical performance despite modest space overhead.</p>
-<h4 id="recommended-encoding-strategy"><strong>Recommended encoding
-strategy</strong></h4>
-<p><strong>Hybrid approach</strong> balancing theory and practice:</p>
-<ol type="1">
-<li><strong>Small products</strong> (≤8 fields): Byte-aligned, no offset
-table</li>
-<li><strong>Medium products</strong> (9-64 fields): Word-aligned with
-offset table</li>
-<li><strong>Large products</strong> (65+ fields): Hierarchical offset
-tables + prefetching</li>
-<li><strong>Unions</strong>: Single byte discriminator (sufficient for
-99.9% of real types)</li>
-</ol>
-<p><strong>Encoding format</strong>:</p>
-<div class="sourceCode" id="cb51"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb51-1"><a href="#cb51-1" aria-hidden="true" tabindex="-1"></a><span class="kw">struct</span> OptimalEncoding <span class="op">{</span></span>
-<span id="cb51-2"><a href="#cb51-2" aria-hidden="true" tabindex="-1"></a>    <span class="dt">uint8_t</span>  type_tag<span class="op">;</span>              <span class="co">// 1 byte: product/union/external marker</span></span>
-<span id="cb51-3"><a href="#cb51-3" aria-hidden="true" tabindex="-1"></a>    <span class="dt">uint8_t</span>  arity<span class="op">;</span>                 <span class="co">// 1 byte: number of children (0-255)</span></span>
-<span id="cb51-4"><a href="#cb51-4" aria-hidden="true" tabindex="-1"></a>    <span class="dt">uint16_t</span> flags<span class="op">;</span>                 <span class="co">// 2 bytes: compression flags, alignment info</span></span>
-<span id="cb51-5"><a href="#cb51-5" aria-hidden="true" tabindex="-1"></a>    <span class="dt">uint32_t</span> total_size<span class="op">;</span>            <span class="co">// 4 bytes: total size for skipping</span></span>
-<span id="cb51-6"><a href="#cb51-6" aria-hidden="true" tabindex="-1"></a>    </span>
-<span id="cb51-7"><a href="#cb51-7" aria-hidden="true" tabindex="-1"></a>    <span class="co">// For products with &gt;8 fields:</span></span>
-<span id="cb51-8"><a href="#cb51-8" aria-hidden="true" tabindex="-1"></a>    <span class="dt">uint32_t</span> field_offsets<span class="op">[</span>arity<span class="op">];</span>  <span class="co">// 4×N bytes: random access table</span></span>
-<span id="cb51-9"><a href="#cb51-9" aria-hidden="true" tabindex="-1"></a>    </span>
-<span id="cb51-10"><a href="#cb51-10" aria-hidden="true" tabindex="-1"></a>    <span class="co">// Payload data follows</span></span>
-<span id="cb51-11"><a href="#cb51-11" aria-hidden="true" tabindex="-1"></a>    <span class="dt">uint8_t</span>  data<span class="op">[];</span></span>
-<span id="cb51-12"><a href="#cb51-12" aria-hidden="true" tabindex="-1"></a><span class="op">};</span></span></code></pre></div>
-<p><strong>Benefits</strong>:</p>
-<ul>
-<li><strong>8-byte aligned</strong> structures for optimal memory
-access</li>
-<li><strong>Single cache line</strong> headers for small products<br />
-</li>
-<li><strong>SIMD-friendly</strong> data layout</li>
-<li><strong>Prefetch-optimized</strong> for large structures</li>
-<li><strong>Hardware-agnostic</strong> but optimized for common
-architectures</li>
-</ul>
-<h3 id="external-type-integration"><strong>6.4.4 External type
-integration</strong></h3>
-<pre class="text"><code>| External Marker (2 bits) | Type ID | External Data Length | External Data |</code></pre>
-<p>This allows built-in types (strings, floats, etc.) to be efficiently
-serialized within <code>k</code> values while maintaining the canonical
-property.</p>
-<hr />
-<h2 id="demand-driven-deserialization"><strong>6.5 Demand-driven
-deserialization</strong></h2>
-<p>Operations on values trigger selective deserialization:</p>
-<h3 id="access-patterns"><strong>6.5.1 Access patterns</strong></h3>
-<ul>
-<li><strong>Identity operation <code>()</code></strong> — no
-deserialization, direct bitstream copy</li>
-<li><strong>Field access <code>.field</code></strong> — deserialize only
-the path to the requested field</li>
-<li><strong>Pattern matching</strong> — deserialize only the
-discriminator, then the matched branch</li>
-<li><strong>Full evaluation</strong> — progressive deserialization as
-computation proceeds</li>
-</ul>
-<h3 id="lazy-evaluation-strategy"><strong>6.5.2 Lazy evaluation
-strategy</strong></h3>
-<div class="sourceCode" id="cb53"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb53-1"><a href="#cb53-1" aria-hidden="true" tabindex="-1"></a>function access_field<span class="op">(</span>value<span class="op">:</span> KValue<span class="op">,</span> field_path<span class="op">:</span> String<span class="op">[]):</span> KValue <span class="op">{</span></span>
-<span id="cb53-2"><a href="#cb53-2" aria-hidden="true" tabindex="-1"></a>    <span class="cf">if</span> <span class="op">(</span>value<span class="op">.</span>form <span class="op">==</span> SERIALIZED<span class="op">)</span> <span class="op">{</span></span>
-<span id="cb53-3"><a href="#cb53-3" aria-hidden="true" tabindex="-1"></a>        <span class="co">// Partially deserialize to reach the field</span></span>
-<span id="cb53-4"><a href="#cb53-4" aria-hidden="true" tabindex="-1"></a>        root <span class="op">=</span> deserialize_to_depth<span class="op">(</span>value<span class="op">,</span> field_path<span class="op">.</span>length<span class="op">);</span></span>
-<span id="cb53-5"><a href="#cb53-5" aria-hidden="true" tabindex="-1"></a>        value <span class="op">=</span> make_lazy<span class="op">(</span>root<span class="op">,</span> value<span class="op">.</span>serialized<span class="op">.</span>bits<span class="op">);</span></span>
-<span id="cb53-6"><a href="#cb53-6" aria-hidden="true" tabindex="-1"></a>    <span class="op">}</span></span>
-<span id="cb53-7"><a href="#cb53-7" aria-hidden="true" tabindex="-1"></a>    </span>
-<span id="cb53-8"><a href="#cb53-8" aria-hidden="true" tabindex="-1"></a>    <span class="cf">if</span> <span class="op">(</span>value<span class="op">.</span>form <span class="op">==</span> LAZY<span class="op">)</span> <span class="op">{</span></span>
-<span id="cb53-9"><a href="#cb53-9" aria-hidden="true" tabindex="-1"></a>        node <span class="op">=</span> navigate_path<span class="op">(</span>value<span class="op">.</span>lazy<span class="op">.</span>root<span class="op">,</span> field_path<span class="op">);</span></span>
-<span id="cb53-10"><a href="#cb53-10" aria-hidden="true" tabindex="-1"></a>        <span class="cf">if</span> <span class="op">(</span>node<span class="op">.</span>child<span class="op">[</span>field_idx<span class="op">].</span>state <span class="op">==</span> SERIALIZED_CHILD<span class="op">)</span> <span class="op">{</span></span>
-<span id="cb53-11"><a href="#cb53-11" aria-hidden="true" tabindex="-1"></a>            <span class="co">// Deserialize this child on demand</span></span>
-<span id="cb53-12"><a href="#cb53-12" aria-hidden="true" tabindex="-1"></a>            child_value <span class="op">=</span> deserialize_child<span class="op">(</span>node<span class="op">,</span> field_idx<span class="op">);</span></span>
-<span id="cb53-13"><a href="#cb53-13" aria-hidden="true" tabindex="-1"></a>            node<span class="op">.</span>child<span class="op">[</span>field_idx<span class="op">].</span>state <span class="op">=</span> MATERIALIZED_CHILD<span class="op">;</span></span>
-<span id="cb53-14"><a href="#cb53-14" aria-hidden="true" tabindex="-1"></a>            node<span class="op">.</span>child<span class="op">[</span>field_idx<span class="op">].</span>node <span class="op">=</span> child_value<span class="op">;</span></span>
-<span id="cb53-15"><a href="#cb53-15" aria-hidden="true" tabindex="-1"></a>        <span class="op">}</span></span>
-<span id="cb53-16"><a href="#cb53-16" aria-hidden="true" tabindex="-1"></a>        <span class="cf">return</span> <span class="op">&amp;</span>node<span class="op">.</span>child<span class="op">[</span>field_idx<span class="op">];</span></span>
-<span id="cb53-17"><a href="#cb53-17" aria-hidden="true" tabindex="-1"></a>    <span class="op">}</span></span>
-<span id="cb53-18"><a href="#cb53-18" aria-hidden="true" tabindex="-1"></a>    </span>
-<span id="cb53-19"><a href="#cb53-19" aria-hidden="true" tabindex="-1"></a>    <span class="co">// Traditional navigation for fully materialized values</span></span>
-<span id="cb53-20"><a href="#cb53-20" aria-hidden="true" tabindex="-1"></a>    <span class="cf">return</span> navigate_materialized<span class="op">(</span>value<span class="op">,</span> field_path<span class="op">);</span></span>
-<span id="cb53-21"><a href="#cb53-21" aria-hidden="true" tabindex="-1"></a><span class="op">}</span></span></code></pre></div>
-<hr />
-<h2 id="external-type-system"><strong>6.6 External type
-system</strong></h2>
-<p>Built-in and foreign types integrate through a plugin interface:</p>
-<h3 id="external-operations"><strong>6.6.1 External
-operations</strong></h3>
-<div class="sourceCode" id="cb54"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb54-1"><a href="#cb54-1" aria-hidden="true" tabindex="-1"></a><span class="kw">struct</span> ExternalOps <span class="op">{</span></span>
-<span id="cb54-2"><a href="#cb54-2" aria-hidden="true" tabindex="-1"></a>    KValue<span class="op">*</span> <span class="op">(*</span>serialize<span class="op">)(</span><span class="dt">void</span><span class="op">*</span> data<span class="op">);</span></span>
-<span id="cb54-3"><a href="#cb54-3" aria-hidden="true" tabindex="-1"></a>    <span class="dt">void</span><span class="op">*</span>   <span class="op">(*</span>deserialize<span class="op">)(</span>KValue<span class="op">*</span> serialized<span class="op">);</span></span>
-<span id="cb54-4"><a href="#cb54-4" aria-hidden="true" tabindex="-1"></a>    KValue<span class="op">*</span> <span class="op">(*</span>apply_function<span class="op">)(</span><span class="dt">void</span><span class="op">*</span> data<span class="op">,</span> <span class="dt">const</span> <span class="dt">char</span><span class="op">*</span> func_name<span class="op">,</span> KValue<span class="op">*</span> args<span class="op">);</span></span>
-<span id="cb54-5"><a href="#cb54-5" aria-hidden="true" tabindex="-1"></a>    <span class="dt">bool</span>    <span class="op">(*</span>equals<span class="op">)(</span><span class="dt">void</span><span class="op">*</span> a<span class="op">,</span> <span class="dt">void</span><span class="op">*</span> b<span class="op">);</span></span>
-<span id="cb54-6"><a href="#cb54-6" aria-hidden="true" tabindex="-1"></a>    <span class="dt">uint64_t</span> <span class="op">(*</span>hash<span class="op">)(</span><span class="dt">void</span><span class="op">*</span> data<span class="op">);</span></span>
-<span id="cb54-7"><a href="#cb54-7" aria-hidden="true" tabindex="-1"></a>    <span class="dt">void</span>    <span class="op">(*</span>destroy<span class="op">)(</span><span class="dt">void</span><span class="op">*</span> data<span class="op">);</span></span>
-<span id="cb54-8"><a href="#cb54-8" aria-hidden="true" tabindex="-1"></a><span class="op">};</span></span></code></pre></div>
-<h3 id="built-in-type-examples"><strong>6.6.2 Built-in type
-examples</strong></h3>
-<ul>
-<li><strong>Strings</strong> — UTF-8 encoded with length prefix</li>
-<li><strong>Integers</strong> — variable-length encoding (LEB128)</li>
-<li><strong>Floats</strong> — IEEE 754 binary representation</li>
-<li><strong>Blobs</strong> — raw binary data with length prefix</li>
-<li><strong>Handles</strong> — opaque references to external
-resources</li>
-</ul>
-<h3 id="type-registration"><strong>6.6.3 Type registration</strong></h3>
-<div class="sourceCode" id="cb55"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb55-1"><a href="#cb55-1" aria-hidden="true" tabindex="-1"></a><span class="dt">void</span> register_external_type<span class="op">(</span><span class="dt">int</span> type_id<span class="op">,</span> <span class="dt">const</span> <span class="dt">char</span><span class="op">*</span> name<span class="op">,</span> ExternalOps<span class="op">*</span> ops<span class="op">)</span> <span class="op">{</span></span>
-<span id="cb55-2"><a href="#cb55-2" aria-hidden="true" tabindex="-1"></a>    external_types<span class="op">[</span>type_id<span class="op">]</span> <span class="op">=</span> <span class="op">{</span></span>
-<span id="cb55-3"><a href="#cb55-3" aria-hidden="true" tabindex="-1"></a>        <span class="op">.</span>name <span class="op">=</span> name<span class="op">,</span></span>
-<span id="cb55-4"><a href="#cb55-4" aria-hidden="true" tabindex="-1"></a>        <span class="op">.</span>ops <span class="op">=</span> ops<span class="op">,</span></span>
-<span id="cb55-5"><a href="#cb55-5" aria-hidden="true" tabindex="-1"></a>        <span class="op">.</span>canonical_hash <span class="op">=</span> compute_type_hash<span class="op">(</span>name<span class="op">,</span> ops<span class="op">-&gt;</span>signature<span class="op">)</span></span>
-<span id="cb55-6"><a href="#cb55-6" aria-hidden="true" tabindex="-1"></a>    <span class="op">};</span></span>
-<span id="cb55-7"><a href="#cb55-7" aria-hidden="true" tabindex="-1"></a><span class="op">}</span></span></code></pre></div>
-<hr />
-<h2 id="memory-management-and-performance"><strong>6.7 Memory management
-and performance</strong></h2>
-<h3 id="arena-allocation"><strong>6.7.1 Arena allocation</strong></h3>
-<p>All materialized nodes use arena allocation for fast allocation and
-bulk deallocation:</p>
-<div class="sourceCode" id="cb56"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb56-1"><a href="#cb56-1" aria-hidden="true" tabindex="-1"></a><span class="kw">struct</span> Arena <span class="op">{</span></span>
-<span id="cb56-2"><a href="#cb56-2" aria-hidden="true" tabindex="-1"></a>    <span class="dt">uint8_t</span><span class="op">*</span> memory<span class="op">;</span></span>
-<span id="cb56-3"><a href="#cb56-3" aria-hidden="true" tabindex="-1"></a>    <span class="dt">size_t</span>   capacity<span class="op">;</span></span>
-<span id="cb56-4"><a href="#cb56-4" aria-hidden="true" tabindex="-1"></a>    <span class="dt">size_t</span>   used<span class="op">;</span></span>
-<span id="cb56-5"><a href="#cb56-5" aria-hidden="true" tabindex="-1"></a>    Arena<span class="op">*</span>   next<span class="op">;</span>      <span class="co">// linked list of arena blocks</span></span>
-<span id="cb56-6"><a href="#cb56-6" aria-hidden="true" tabindex="-1"></a><span class="op">};</span></span></code></pre></div>
-<h3 id="sharing-and-deduplication"><strong>6.7.2 Sharing and
-deduplication</strong></h3>
-<ul>
-<li><strong>Canonical folding</strong> — identical subtrees share the
-same materialized nodes</li>
-<li><strong>Bitstream sharing</strong> — multiple lazy values can
-reference the same underlying bitstream</li>
-<li><strong>DAG back-references</strong> — shared subtrees in serialized
-form avoid duplication during lazy materialization</li>
-<li><strong>External sharing</strong> — external values use reference
-counting or garbage collection as appropriate</li>
-</ul>
-<h3 id="optimization-opportunities"><strong>6.7.3 Optimization
-opportunities</strong></h3>
-<ul>
-<li><strong>Zero-copy operations</strong> — identity, field projection
-on serialized values</li>
-<li><strong>Streaming evaluation</strong> — process large datasets
-without full materialization<br />
-</li>
-<li><strong>Parallel deserialization</strong> — independent subtrees can
-be materialized concurrently</li>
-<li><strong>DAG-aware caching</strong> — cache resolutions of frequently
-accessed back-references</li>
-<li><strong>Memoization</strong> — cache frequently accessed paths in
-lazy structures</li>
-</ul>
-<hr />
-<h2 id="example-lazy-evaluation-in-practice"><strong>6.8 Example: Lazy
-evaluation in practice</strong></h2>
-<p>Consider processing a large JSON-like structure where we only need
-one field:</p>
-<pre class="k-lang"><code>$record = { string name, list data, metadata meta };
-$list = &lt; {nat value, list next} cons, {} nil &gt;;
-$metadata = { timestamp created, string author };</code></pre>
-<p>For the input program <code>\x.x.name</code> (extract name
-field):</p>
-<ol type="1">
-<li><strong>Input</strong> arrives as serialized bitstream (e.g., from
-network/disk)</li>
-<li><strong>Lazy parsing</strong> deserializes only the discriminator of
-the root product</li>
-<li><strong>Field access</strong> deserializes path to <code>name</code>
-field, leaving <code>data</code> and <code>meta</code> serialized</li>
-<li><strong>Output</strong> the extracted string value (possibly in
-external string format)</li>
-</ol>
-<p>The entire <code>data</code> list and <code>metadata</code> remain as
-untouched bitstreams, providing massive performance benefits for large,
-sparsely accessed data structures.</p>
-<h3 id="serialized-representation"><strong>6.8.1 Serialized
-representation</strong></h3>
-<p>The same value can exist in different forms simultaneously:</p>
-<div class="sourceCode" id="cb58"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb58-1"><a href="#cb58-1" aria-hidden="true" tabindex="-1"></a><span class="co">// Original input: fully serialized</span></span>
-<span id="cb58-2"><a href="#cb58-2" aria-hidden="true" tabindex="-1"></a>KValue input <span class="op">=</span> <span class="op">{</span></span>
-<span id="cb58-3"><a href="#cb58-3" aria-hidden="true" tabindex="-1"></a>    <span class="op">.</span>form <span class="op">=</span> SERIALIZED<span class="op">,</span></span>
-<span id="cb58-4"><a href="#cb58-4" aria-hidden="true" tabindex="-1"></a>    <span class="op">.</span>serialized <span class="op">=</span> <span class="op">{</span></span>
-<span id="cb58-5"><a href="#cb58-5" aria-hidden="true" tabindex="-1"></a>        <span class="op">.</span>bits <span class="op">=</span> bitstream_buffer<span class="op">,</span></span>
-<span id="cb58-6"><a href="#cb58-6" aria-hidden="true" tabindex="-1"></a>        <span class="op">.</span>type_hash <span class="op">=</span> hash<span class="op">(</span><span class="st">&quot;record&quot;</span><span class="op">)</span></span>
-<span id="cb58-7"><a href="#cb58-7" aria-hidden="true" tabindex="-1"></a>    <span class="op">}</span></span>
-<span id="cb58-8"><a href="#cb58-8" aria-hidden="true" tabindex="-1"></a><span class="op">};</span></span>
-<span id="cb58-9"><a href="#cb58-9" aria-hidden="true" tabindex="-1"></a></span>
-<span id="cb58-10"><a href="#cb58-10" aria-hidden="true" tabindex="-1"></a><span class="co">// After partial access: hybrid lazy</span></span>
-<span id="cb58-11"><a href="#cb58-11" aria-hidden="true" tabindex="-1"></a>KValue hybrid <span class="op">=</span> <span class="op">{</span></span>
-<span id="cb58-12"><a href="#cb58-12" aria-hidden="true" tabindex="-1"></a>    <span class="op">.</span>form <span class="op">=</span> LAZY<span class="op">,</span></span>
-<span id="cb58-13"><a href="#cb58-13" aria-hidden="true" tabindex="-1"></a>    <span class="op">.</span>lazy<span class="op">.</span>root <span class="op">=</span> <span class="op">{</span></span>
-<span id="cb58-14"><a href="#cb58-14" aria-hidden="true" tabindex="-1"></a>        <span class="op">.</span>state <span class="op">=</span> <span class="dv">0</span><span class="op">,</span> <span class="op">.</span>tag <span class="op">=</span> <span class="op">-</span><span class="dv">1</span><span class="op">,</span> <span class="op">.</span>arity <span class="op">=</span> <span class="dv">3</span><span class="op">,</span></span>
-<span id="cb58-15"><a href="#cb58-15" aria-hidden="true" tabindex="-1"></a>        <span class="op">.</span>child <span class="op">=</span> <span class="op">{</span></span>
-<span id="cb58-16"><a href="#cb58-16" aria-hidden="true" tabindex="-1"></a>            <span class="op">[</span><span class="dv">0</span><span class="op">]</span> <span class="op">=</span> <span class="op">{</span> <span class="op">.</span>state <span class="op">=</span> MATERIALIZED_CHILD<span class="op">,</span> <span class="op">.</span>node <span class="op">=</span> materialized_string_node <span class="op">},</span>      <span class="co">// name: materialized</span></span>
-<span id="cb58-17"><a href="#cb58-17" aria-hidden="true" tabindex="-1"></a>            <span class="op">[</span><span class="dv">1</span><span class="op">]</span> <span class="op">=</span> <span class="op">{</span> <span class="op">.</span>state <span class="op">=</span> SERIALIZED_CHILD<span class="op">,</span> <span class="op">.</span>serialized <span class="op">=</span> <span class="op">{</span>bits<span class="op">+</span>offset<span class="op">,</span> <span class="dv">64</span><span class="op">}</span> <span class="op">},</span>        <span class="co">// data: still serialized  </span></span>
-<span id="cb58-18"><a href="#cb58-18" aria-hidden="true" tabindex="-1"></a>            <span class="op">[</span><span class="dv">2</span><span class="op">]</span> <span class="op">=</span> <span class="op">{</span> <span class="op">.</span>state <span class="op">=</span> SERIALIZED_CHILD<span class="op">,</span> <span class="op">.</span>serialized <span class="op">=</span> <span class="op">{</span>bits<span class="op">+</span>offset<span class="op">,</span> <span class="dv">1088</span><span class="op">}</span> <span class="op">}</span>       <span class="co">// meta: still serialized</span></span>
-<span id="cb58-19"><a href="#cb58-19" aria-hidden="true" tabindex="-1"></a>        <span class="op">}</span></span>
-<span id="cb58-20"><a href="#cb58-20" aria-hidden="true" tabindex="-1"></a>    <span class="op">}</span></span>
-<span id="cb58-21"><a href="#cb58-21" aria-hidden="true" tabindex="-1"></a><span class="op">};</span></span></code></pre></div>
-<h3 id="external-type-integration-example"><strong>6.8.2 External type
-integration example</strong></h3>
-<div class="sourceCode" id="cb59"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb59-1"><a href="#cb59-1" aria-hidden="true" tabindex="-1"></a><span class="co">// Built-in string type</span></span>
-<span id="cb59-2"><a href="#cb59-2" aria-hidden="true" tabindex="-1"></a>KValue string_value <span class="op">=</span> <span class="op">{</span></span>
-<span id="cb59-3"><a href="#cb59-3" aria-hidden="true" tabindex="-1"></a>    <span class="op">.</span>form <span class="op">=</span> EXTERNAL<span class="op">,</span></span>
-<span id="cb59-4"><a href="#cb59-4" aria-hidden="true" tabindex="-1"></a>    <span class="op">.</span>external <span class="op">=</span> <span class="op">{</span></span>
-<span id="cb59-5"><a href="#cb59-5" aria-hidden="true" tabindex="-1"></a>        <span class="op">.</span>data <span class="op">=</span> utf8_string_data<span class="op">,</span></span>
-<span id="cb59-6"><a href="#cb59-6" aria-hidden="true" tabindex="-1"></a>        <span class="op">.</span>type_id <span class="op">=</span> BUILTIN_STRING<span class="op">,</span></span>
-<span id="cb59-7"><a href="#cb59-7" aria-hidden="true" tabindex="-1"></a>        <span class="op">.</span>ops <span class="op">=</span> <span class="op">&amp;</span>string_operations</span>
-<span id="cb59-8"><a href="#cb59-8" aria-hidden="true" tabindex="-1"></a>    <span class="op">}</span></span>
-<span id="cb59-9"><a href="#cb59-9" aria-hidden="true" tabindex="-1"></a><span class="op">};</span></span>
-<span id="cb59-10"><a href="#cb59-10" aria-hidden="true" tabindex="-1"></a></span>
-<span id="cb59-11"><a href="#cb59-11" aria-hidden="true" tabindex="-1"></a><span class="co">// The string_operations provide:</span></span>
-<span id="cb59-12"><a href="#cb59-12" aria-hidden="true" tabindex="-1"></a>ExternalOps string_operations <span class="op">=</span> <span class="op">{</span></span>
-<span id="cb59-13"><a href="#cb59-13" aria-hidden="true" tabindex="-1"></a>    <span class="op">.</span>serialize <span class="op">=</span> string_to_canonical_bits<span class="op">,</span></span>
-<span id="cb59-14"><a href="#cb59-14" aria-hidden="true" tabindex="-1"></a>    <span class="op">.</span>deserialize <span class="op">=</span> canonical_bits_to_string<span class="op">,</span></span>
-<span id="cb59-15"><a href="#cb59-15" aria-hidden="true" tabindex="-1"></a>    <span class="op">.</span>apply_function <span class="op">=</span> string_builtin_functions<span class="op">,</span>  <span class="co">// length, concat, etc.</span></span>
-<span id="cb59-16"><a href="#cb59-16" aria-hidden="true" tabindex="-1"></a>    <span class="op">.</span>equals <span class="op">=</span> utf8_string_compare<span class="op">,</span></span>
-<span id="cb59-17"><a href="#cb59-17" aria-hidden="true" tabindex="-1"></a>    <span class="op">.</span>hash <span class="op">=</span> utf8_string_hash<span class="op">,</span></span>
-<span id="cb59-18"><a href="#cb59-18" aria-hidden="true" tabindex="-1"></a>    <span class="op">.</span>destroy <span class="op">=</span> free_string_data</span>
-<span id="cb59-19"><a href="#cb59-19" aria-hidden="true" tabindex="-1"></a><span class="op">};</span></span></code></pre></div>
-<hr />
-<h2 id="summary-4"><strong>6.9 Summary</strong></h2>
-<p>This unified representation provides several key advantages:</p>
-<ul>
-<li><strong>Performance</strong> — avoid unnecessary deserialization
-through lazy evaluation</li>
-<li><strong>Memory efficiency</strong> — share serialized data between
-multiple references</li>
-<li><strong>Composability</strong> — external types integrate seamlessly
-with k’s type system</li>
-<li><strong>Streaming</strong> — process large data structures with
-bounded memory usage</li>
-<li><strong>Determinism</strong> — canonical serialization ensures
-reproducible computation</li>
-</ul>
-<p>The design supports the full spectrum from zero-copy identity
-operations to fully materialized tree traversal, allowing the runtime to
-automatically choose the most efficient representation for each use
-case.</p>
-<h3 id="key-design-principles"><strong>6.9.1 Key design
-principles</strong></h3>
-<ul>
-<li><strong>Immutability</strong> — all representations are immutable,
-enabling safe sharing</li>
-<li><strong>Demand-driven</strong> — materialization happens only when
-computation requires it</li>
-<li><strong>Canonical</strong> — serialized forms are deterministic and
-hashable</li>
-<li><strong>Extensible</strong> — external types extend the system
-without breaking canonical properties</li>
-<li><strong>Unified</strong> — single abstraction handles all value
-representations</li>
-</ul>
-<hr />
-<h2 id="execution-model-with-decorated-pointers"><strong>6.10 Execution
-model with decorated pointers</strong></h2>
-<p>The formal execution model is based on decorated pointers, which
-represent values during execution:</p>
-<h3 id="decorated-pointers"><strong>6.10.1 Decorated
-pointers</strong></h3>
-<p>Every value during execution is represented by a <strong>decorated
-pointer</strong>:</p>
-<div class="sourceCode" id="cb60"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb60-1"><a href="#cb60-1" aria-hidden="true" tabindex="-1"></a><span class="kw">struct</span> DecoratedPtr <span class="op">{</span></span>
-<span id="cb60-2"><a href="#cb60-2" aria-hidden="true" tabindex="-1"></a>    <span class="dt">uint8_t</span><span class="op">*</span>     bits<span class="op">;</span>          <span class="co">// pointer into serialized input heap</span></span>
-<span id="cb60-3"><a href="#cb60-3" aria-hidden="true" tabindex="-1"></a>    <span class="dt">size_t</span>       bit_offset<span class="op">;</span>    <span class="co">// bit position within the stream</span></span>
-<span id="cb60-4"><a href="#cb60-4" aria-hidden="true" tabindex="-1"></a>    TypeState    type_state<span class="op">;</span>    <span class="co">// canonical automaton state (C0, C1, ...)</span></span>
-<span id="cb60-5"><a href="#cb60-5" aria-hidden="true" tabindex="-1"></a>    <span class="dt">int</span>          ref_count<span class="op">;</span>     <span class="co">// for sharing and caching</span></span>
-<span id="cb60-6"><a href="#cb60-6" aria-hidden="true" tabindex="-1"></a>    <span class="kw">struct</span> <span class="op">{</span></span>
-<span id="cb60-7"><a href="#cb60-7" aria-hidden="true" tabindex="-1"></a>        <span class="dt">bool</span>     is_cached<span class="op">;</span>     <span class="co">// memoization flag</span></span>
-<span id="cb60-8"><a href="#cb60-8" aria-hidden="true" tabindex="-1"></a>        <span class="dt">uint64_t</span> content_hash<span class="op">;</span>  <span class="co">// for cache lookup</span></span>
-<span id="cb60-9"><a href="#cb60-9" aria-hidden="true" tabindex="-1"></a>    <span class="op">}</span> cache<span class="op">;</span></span>
-<span id="cb60-10"><a href="#cb60-10" aria-hidden="true" tabindex="-1"></a><span class="op">};</span></span></code></pre></div>
-<p>The key insight: <strong>decorated pointers are lightweight and can
-be computed without memory allocation</strong>.</p>
-<h3 id="program-execution-pipeline"><strong>6.10.2 Program execution
-pipeline</strong></h3>
-<p>A compiled k program is a composition of operations:
-<code>projection ∘ product ∘ union ∘ builtin_call ∘ ...</code></p>
-<p>Each operation transforms a decorated pointer:</p>
-<pre class="text"><code>DecoratedPtr → DecoratedPtr</code></pre>
-<h4 id="projection-operation"><strong>Projection operation</strong></h4>
-<p>For field access <code>.field_name</code>:</p>
-<div class="sourceCode" id="cb62"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb62-1"><a href="#cb62-1" aria-hidden="true" tabindex="-1"></a>DecoratedPtr project_field_optimized<span class="op">(</span>DecoratedPtr input<span class="op">,</span> <span class="dt">int</span> field_index<span class="op">)</span> <span class="op">{</span></span>
-<span id="cb62-2"><a href="#cb62-2" aria-hidden="true" tabindex="-1"></a>    <span class="co">// Hardware-optimized field navigation</span></span>
-<span id="cb62-3"><a href="#cb62-3" aria-hidden="true" tabindex="-1"></a>    <span class="dt">uint8_t</span><span class="op">*</span> byte_ptr <span class="op">=</span> input<span class="op">.</span>bits <span class="op">+</span> <span class="op">(</span>input<span class="op">.</span>bit_offset <span class="op">&gt;&gt;</span> <span class="dv">3</span><span class="op">);</span></span>
-<span id="cb62-4"><a href="#cb62-4" aria-hidden="true" tabindex="-1"></a>    </span>
-<span id="cb62-5"><a href="#cb62-5" aria-hidden="true" tabindex="-1"></a>    <span class="co">// Read encoding header</span></span>
-<span id="cb62-6"><a href="#cb62-6" aria-hidden="true" tabindex="-1"></a>    <span class="kw">struct</span> OptimalEncoding<span class="op">*</span> header <span class="op">=</span> <span class="op">(</span><span class="kw">struct</span> OptimalEncoding<span class="op">*)</span>byte_ptr<span class="op">;</span></span>
-<span id="cb62-7"><a href="#cb62-7" aria-hidden="true" tabindex="-1"></a>    </span>
-<span id="cb62-8"><a href="#cb62-8" aria-hidden="true" tabindex="-1"></a>    <span class="cf">if</span> <span class="op">(</span>header<span class="op">-&gt;</span>arity <span class="op">&lt;=</span> <span class="dv">8</span><span class="op">)</span> <span class="op">{</span></span>
-<span id="cb62-9"><a href="#cb62-9" aria-hidden="true" tabindex="-1"></a>        <span class="co">// Small product: sequential scan (cache-friendly)</span></span>
-<span id="cb62-10"><a href="#cb62-10" aria-hidden="true" tabindex="-1"></a>        <span class="dt">uint8_t</span><span class="op">*</span> field_ptr <span class="op">=</span> byte_ptr <span class="op">+</span> <span class="kw">sizeof</span><span class="op">(</span><span class="kw">struct</span> OptimalEncoding<span class="op">);</span></span>
-<span id="cb62-11"><a href="#cb62-11" aria-hidden="true" tabindex="-1"></a>        <span class="cf">for</span> <span class="op">(</span><span class="dt">int</span> i <span class="op">=</span> <span class="dv">0</span><span class="op">;</span> i <span class="op">&lt;</span> field_index<span class="op">;</span> i<span class="op">++)</span> <span class="op">{</span></span>
-<span id="cb62-12"><a href="#cb62-12" aria-hidden="true" tabindex="-1"></a>            <span class="dt">uint32_t</span> field_size <span class="op">=</span> <span class="op">*(</span><span class="dt">uint32_t</span><span class="op">*)</span>field_ptr<span class="op">;</span>  <span class="co">// First 4 bytes = size</span></span>
-<span id="cb62-13"><a href="#cb62-13" aria-hidden="true" tabindex="-1"></a>            field_ptr <span class="op">+=</span> field_size<span class="op">;</span></span>
-<span id="cb62-14"><a href="#cb62-14" aria-hidden="true" tabindex="-1"></a>        <span class="op">}</span></span>
-<span id="cb62-15"><a href="#cb62-15" aria-hidden="true" tabindex="-1"></a>        <span class="cf">return</span> make_ptr_from_bytes<span class="op">(</span>field_ptr<span class="op">);</span></span>
-<span id="cb62-16"><a href="#cb62-16" aria-hidden="true" tabindex="-1"></a>    <span class="op">}</span> <span class="cf">else</span> <span class="op">{</span></span>
-<span id="cb62-17"><a href="#cb62-17" aria-hidden="true" tabindex="-1"></a>        <span class="co">// Large product: offset table lookup (O(1) access)</span></span>
-<span id="cb62-18"><a href="#cb62-18" aria-hidden="true" tabindex="-1"></a>        <span class="dt">uint32_t</span> field_offset <span class="op">=</span> header<span class="op">-&gt;</span>field_offsets<span class="op">[</span>field_index<span class="op">];</span></span>
-<span id="cb62-19"><a href="#cb62-19" aria-hidden="true" tabindex="-1"></a>        <span class="cf">return</span> make_ptr_from_bytes<span class="op">(</span>byte_ptr <span class="op">+</span> field_offset<span class="op">);</span></span>
-<span id="cb62-20"><a href="#cb62-20" aria-hidden="true" tabindex="-1"></a>    <span class="op">}</span></span>
-<span id="cb62-21"><a href="#cb62-21" aria-hidden="true" tabindex="-1"></a><span class="op">}</span></span></code></pre></div>
-<p><strong>Key property</strong>: Hardware-optimized navigation using
-word-aligned loads and offset tables.</p>
-<h4 id="union-operation"><strong>Union operation</strong></h4>
-<p>For pattern matching
-<code>case { tag1 → ..., tag2 → ... }</code>:</p>
-<div class="sourceCode" id="cb63"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb63-1"><a href="#cb63-1" aria-hidden="true" tabindex="-1"></a>DecoratedPtr match_union_optimized<span class="op">(</span>DecoratedPtr input<span class="op">,</span> <span class="dt">int</span> expected_tag<span class="op">)</span> <span class="op">{</span></span>
-<span id="cb63-2"><a href="#cb63-2" aria-hidden="true" tabindex="-1"></a>    <span class="co">// Read single-byte discriminator (hardware-friendly)</span></span>
-<span id="cb63-3"><a href="#cb63-3" aria-hidden="true" tabindex="-1"></a>    <span class="dt">uint8_t</span><span class="op">*</span> byte_ptr <span class="op">=</span> input<span class="op">.</span>bits <span class="op">+</span> <span class="op">(</span>input<span class="op">.</span>bit_offset <span class="op">&gt;&gt;</span> <span class="dv">3</span><span class="op">);</span></span>
-<span id="cb63-4"><a href="#cb63-4" aria-hidden="true" tabindex="-1"></a>    <span class="kw">struct</span> OptimalEncoding<span class="op">*</span> header <span class="op">=</span> <span class="op">(</span><span class="kw">struct</span> OptimalEncoding<span class="op">*)</span>byte_ptr<span class="op">;</span></span>
-<span id="cb63-5"><a href="#cb63-5" aria-hidden="true" tabindex="-1"></a>    </span>
-<span id="cb63-6"><a href="#cb63-6" aria-hidden="true" tabindex="-1"></a>    <span class="dt">uint8_t</span> actual_tag <span class="op">=</span> header<span class="op">-&gt;</span>data<span class="op">[</span><span class="dv">0</span><span class="op">];</span>  <span class="co">// First byte of data = discriminator</span></span>
-<span id="cb63-7"><a href="#cb63-7" aria-hidden="true" tabindex="-1"></a>    </span>
-<span id="cb63-8"><a href="#cb63-8" aria-hidden="true" tabindex="-1"></a>    <span class="cf">if</span> <span class="op">(</span>actual_tag <span class="op">!=</span> expected_tag<span class="op">)</span> <span class="op">{</span></span>
-<span id="cb63-9"><a href="#cb63-9" aria-hidden="true" tabindex="-1"></a>        <span class="cf">return</span> UNDEFINED_PTR<span class="op">;</span>  <span class="co">// Pattern match failure</span></span>
-<span id="cb63-10"><a href="#cb63-10" aria-hidden="true" tabindex="-1"></a>    <span class="op">}</span></span>
-<span id="cb63-11"><a href="#cb63-11" aria-hidden="true" tabindex="-1"></a>    </span>
-<span id="cb63-12"><a href="#cb63-12" aria-hidden="true" tabindex="-1"></a>    <span class="co">// Skip past header + discriminator</span></span>
-<span id="cb63-13"><a href="#cb63-13" aria-hidden="true" tabindex="-1"></a>    <span class="dt">uint8_t</span><span class="op">*</span> child_ptr <span class="op">=</span> byte_ptr <span class="op">+</span> <span class="kw">sizeof</span><span class="op">(</span><span class="kw">struct</span> OptimalEncoding<span class="op">)</span> <span class="op">+</span> <span class="dv">1</span><span class="op">;</span></span>
-<span id="cb63-14"><a href="#cb63-14" aria-hidden="true" tabindex="-1"></a>    </span>
-<span id="cb63-15"><a href="#cb63-15" aria-hidden="true" tabindex="-1"></a>    <span class="cf">return</span> make_ptr_from_bytes<span class="op">(</span>child_ptr<span class="op">);</span></span>
-<span id="cb63-16"><a href="#cb63-16" aria-hidden="true" tabindex="-1"></a><span class="op">}</span></span></code></pre></div>
-<h4 id="product-operation"><strong>Product operation</strong></h4>
-<p>For product construction <code>{ field1, field2, ... }</code>:</p>
-<div class="sourceCode" id="cb64"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb64-1"><a href="#cb64-1" aria-hidden="true" tabindex="-1"></a>DecoratedPtr construct_product<span class="op">(</span>DecoratedPtr<span class="op">*</span> field_ptrs<span class="op">,</span> <span class="dt">int</span> arity<span class="op">)</span> <span class="op">{</span></span>
-<span id="cb64-2"><a href="#cb64-2" aria-hidden="true" tabindex="-1"></a>    <span class="co">// This is the primary point where memory allocation is required.</span></span>
-<span id="cb64-3"><a href="#cb64-3" aria-hidden="true" tabindex="-1"></a>    ProductNode<span class="op">*</span> result <span class="op">=</span> allocate_product_node<span class="op">(</span>arity<span class="op">);</span></span>
-<span id="cb64-4"><a href="#cb64-4" aria-hidden="true" tabindex="-1"></a>    </span>
-<span id="cb64-5"><a href="#cb64-5" aria-hidden="true" tabindex="-1"></a>    <span class="co">// Evaluate each field (possibly in parallel)</span></span>
-<span id="cb64-6"><a href="#cb64-6" aria-hidden="true" tabindex="-1"></a>    <span class="cf">for</span> <span class="op">(</span><span class="dt">int</span> i <span class="op">=</span> <span class="dv">0</span><span class="op">;</span> i <span class="op">&lt;</span> arity<span class="op">;</span> i<span class="op">++)</span> <span class="op">{</span></span>
-<span id="cb64-7"><a href="#cb64-7" aria-hidden="true" tabindex="-1"></a>        result<span class="op">-&gt;</span>fields<span class="op">[</span>i<span class="op">]</span> <span class="op">=</span> evaluate_expression<span class="op">(</span>field_ptrs<span class="op">[</span>i<span class="op">]);</span></span>
-<span id="cb64-8"><a href="#cb64-8" aria-hidden="true" tabindex="-1"></a>    <span class="op">}</span></span>
-<span id="cb64-9"><a href="#cb64-9" aria-hidden="true" tabindex="-1"></a>    </span>
-<span id="cb64-10"><a href="#cb64-10" aria-hidden="true" tabindex="-1"></a>    <span class="cf">return</span> make_materialized_ptr<span class="op">(</span>result<span class="op">);</span></span>
-<span id="cb64-11"><a href="#cb64-11" aria-hidden="true" tabindex="-1"></a><span class="op">}</span></span></code></pre></div>
-<h4 id="built-in-call-operation"><strong>Built-in call
-operation</strong></h4>
-<p>For external functions <code>string_length</code>,
-<code>add_int</code>, etc.:</p>
-<div class="sourceCode" id="cb65"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb65-1"><a href="#cb65-1" aria-hidden="true" tabindex="-1"></a>DecoratedPtr builtin_call<span class="op">(</span>DecoratedPtr input<span class="op">,</span> BuiltinFunc func<span class="op">)</span> <span class="op">{</span></span>
-<span id="cb65-2"><a href="#cb65-2" aria-hidden="true" tabindex="-1"></a>    <span class="co">// Force materialization of the input</span></span>
-<span id="cb65-3"><a href="#cb65-3" aria-hidden="true" tabindex="-1"></a>    ExternalValue<span class="op">*</span> materialized <span class="op">=</span> force_external<span class="op">(</span>input<span class="op">);</span></span>
-<span id="cb65-4"><a href="#cb65-4" aria-hidden="true" tabindex="-1"></a>    </span>
-<span id="cb65-5"><a href="#cb65-5" aria-hidden="true" tabindex="-1"></a>    <span class="co">// Delegate to external implementation</span></span>
-<span id="cb65-6"><a href="#cb65-6" aria-hidden="true" tabindex="-1"></a>    ExternalValue<span class="op">*</span> result <span class="op">=</span> func<span class="op">-&gt;</span>call<span class="op">(</span>materialized<span class="op">);</span></span>
-<span id="cb65-7"><a href="#cb65-7" aria-hidden="true" tabindex="-1"></a>    </span>
-<span id="cb65-8"><a href="#cb65-8" aria-hidden="true" tabindex="-1"></a>    <span class="cf">return</span> make_external_ptr<span class="op">(</span>result<span class="op">);</span></span>
-<span id="cb65-9"><a href="#cb65-9" aria-hidden="true" tabindex="-1"></a><span class="op">}</span></span></code></pre></div>
-<h3 id="execution-strategy"><strong>6.10.3 Execution
-strategy</strong></h3>
-<ol type="1">
-<li><strong>Input setup</strong>: Place serialized input in heap, create
-root decorated pointer</li>
-<li><strong>Lazy evaluation</strong>: Transform decorated pointers
-without allocation when possible</li>
-<li><strong>Forced materialization</strong>: Allocate memory only when
-constructing products or calling built-ins</li>
-<li><strong>Reference counting</strong>: Share decorated pointers for
-common subexpressions</li>
-<li><strong>Output serialization</strong>: Convert final decorated
-pointer back to canonical bits</li>
-</ol>
-<h3 id="example-execution-trace"><strong>6.10.4 Example execution
-trace</strong></h3>
-<p>For program <code>\x.(x.data.head.value, x.name)</code> on input
-<code>{ name: "alice", data: [42, 17] }</code>:</p>
-<pre class="text"><code>Step 1: input_ptr = {bits: heap_start, offset: 0, state: C0_record}
-
-Step 2: data_ptr = project_field(input_ptr, 1)  // .data
-        = {bits: heap_start, offset: 120, state: C0_list}
-
-Step 3: head_ptr = match_union(data_ptr, CONS_TAG)  // pattern match
-        = {bits: heap_start, offset: 122, state: C0_cons}
-
-Step 4: value_ptr = project_field(head_ptr, 0)  // .value  
-        = {bits: heap_start, offset: 122, state: C0_int}
-
-Step 5: name_ptr = project_field(input_ptr, 0)  // .name
-        = {bits: heap_start, offset: 8, state: C0_string}
-
-Step 6: result_ptr = construct_product([value_ptr, name_ptr])
-        // Note: memory allocation for the result tuple occurs here.</code></pre>
-<h3 id="optimization-opportunities-1"><strong>6.10.5 Optimization
-opportunities</strong></h3>
-<ul>
-<li><strong>Parallel field evaluation</strong> — Independent fields can
-be computed concurrently</li>
-<li><strong>Memoization</strong> — Cache decorated pointers for repeated
-subexpressions<br />
-</li>
-<li><strong>Streaming</strong> — Process parts of large inputs without
-loading everything</li>
-<li><strong>Zero-copy identity</strong> — <code>()</code> just returns
-the input decorated pointer</li>
-<li><strong>Prefix-free parsing</strong> — No backtracking needed,
-linear-time navigation</li>
-</ul>
-<p>This model provides <strong>optimal performance</strong> for sparse
-data access while maintaining the mathematical precision of k’s type
-system.</p>
-<hr />
-<h2 id="implementation-considerations"><strong>6.11 Implementation
-considerations</strong></h2>
-<h3 id="prefix-free-code-requirements"><strong>6.11.1 Prefix-free code
-requirements</strong></h3>
-<p>The execution model depends critically on <strong>prefix-free
-codes</strong> in the serialization:</p>
-<ul>
-<li><strong>Union discriminators</strong> — Fixed-length codes ensure
-constant-time tag reading</li>
-<li><strong>External data</strong> — Length-prefixed to enable skipping
-without parsing</li>
-<li><strong>Product fields</strong> — Implicit boundaries defined by
-type structure</li>
-</ul>
-<p>This enables the <code>skip_field()</code> function to advance
-pointers without full deserialization.</p>
-<h3 id="reference-counting-and-caching"><strong>6.11.2 Reference
-counting and caching</strong></h3>
-<p>Decorated pointers should be reference-counted for several
-reasons:</p>
-<p>Benefits:</p>
-<ul>
-<li><strong>Sharing</strong> — Multiple references to the same
-subexpression</li>
-<li><strong>Caching</strong> — Avoid recomputation of expensive
-operations</li>
-<li><strong>Memory efficiency</strong> — Single copy of large serialized
-inputs</li>
-</ul>
-<h3 id="parallel-evaluation"><strong>6.11.3 Parallel
-evaluation</strong></h3>
-<p>Product construction offers natural parallelization:</p>
-<div class="sourceCode" id="cb67"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb67-1"><a href="#cb67-1" aria-hidden="true" tabindex="-1"></a>DecoratedPtr construct_product_parallel<span class="op">(</span>DecoratedPtr<span class="op">*</span> field_ptrs<span class="op">,</span> <span class="dt">int</span> arity<span class="op">)</span> <span class="op">{</span></span>
-<span id="cb67-2"><a href="#cb67-2" aria-hidden="true" tabindex="-1"></a>    ProductNode<span class="op">*</span> result <span class="op">=</span> allocate_product_node<span class="op">(</span>arity<span class="op">);</span></span>
-<span id="cb67-3"><a href="#cb67-3" aria-hidden="true" tabindex="-1"></a>    </span>
-<span id="cb67-4"><a href="#cb67-4" aria-hidden="true" tabindex="-1"></a>    <span class="pp">#pragma omp parallel for</span></span>
-<span id="cb67-5"><a href="#cb67-5" aria-hidden="true" tabindex="-1"></a>    <span class="cf">for</span> <span class="op">(</span><span class="dt">int</span> i <span class="op">=</span> <span class="dv">0</span><span class="op">;</span> i <span class="op">&lt;</span> arity<span class="op">;</span> i<span class="op">++)</span> <span class="op">{</span></span>
-<span id="cb67-6"><a href="#cb67-6" aria-hidden="true" tabindex="-1"></a>        result<span class="op">-&gt;</span>fields<span class="op">[</span>i<span class="op">]</span> <span class="op">=</span> evaluate_expression<span class="op">(</span>field_ptrs<span class="op">[</span>i<span class="op">]);</span></span>
-<span id="cb67-7"><a href="#cb67-7" aria-hidden="true" tabindex="-1"></a>    <span class="op">}</span></span>
-<span id="cb67-8"><a href="#cb67-8" aria-hidden="true" tabindex="-1"></a>    </span>
-<span id="cb67-9"><a href="#cb67-9" aria-hidden="true" tabindex="-1"></a>    <span class="cf">return</span> make_materialized_ptr<span class="op">(</span>result<span class="op">);</span></span>
-<span id="cb67-10"><a href="#cb67-10" aria-hidden="true" tabindex="-1"></a><span class="op">}</span></span></code></pre></div>
-<p>Each field evaluation is independent and can run on separate
-threads.</p>
-<h3 id="memory-layout-optimization"><strong>6.11.4 Memory layout
-optimization</strong></h3>
-<p>The input heap should be designed for efficient navigation:</p>
-<div class="sourceCode" id="cb68"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb68-1"><a href="#cb68-1" aria-hidden="true" tabindex="-1"></a><span class="kw">struct</span> InputHeap <span class="op">{</span></span>
-<span id="cb68-2"><a href="#cb68-2" aria-hidden="true" tabindex="-1"></a>    <span class="dt">uint8_t</span><span class="op">*</span>  serialized_data<span class="op">;</span>     <span class="co">// the original bitstream</span></span>
-<span id="cb68-3"><a href="#cb68-3" aria-hidden="true" tabindex="-1"></a>    <span class="dt">size_t</span>    total_bits<span class="op">;</span>          <span class="co">// total size</span></span>
-<span id="cb68-4"><a href="#cb68-4" aria-hidden="true" tabindex="-1"></a>    </span>
-<span id="cb68-5"><a href="#cb68-5" aria-hidden="true" tabindex="-1"></a>    <span class="co">// Optional: precomputed navigation table for large inputs</span></span>
-<span id="cb68-6"><a href="#cb68-6" aria-hidden="true" tabindex="-1"></a>    <span class="kw">struct</span> <span class="op">{</span></span>
-<span id="cb68-7"><a href="#cb68-7" aria-hidden="true" tabindex="-1"></a>        <span class="dt">size_t</span><span class="op">*</span>   field_offsets<span class="op">;</span>   <span class="co">// byte offsets for major fields</span></span>
-<span id="cb68-8"><a href="#cb68-8" aria-hidden="true" tabindex="-1"></a>        <span class="dt">int</span>       table_size<span class="op">;</span>      <span class="co">// number of cached offsets</span></span>
-<span id="cb68-9"><a href="#cb68-9" aria-hidden="true" tabindex="-1"></a>    <span class="op">}</span> navigation_cache<span class="op">;</span></span>
-<span id="cb68-10"><a href="#cb68-10" aria-hidden="true" tabindex="-1"></a><span class="op">};</span></span></code></pre></div>
-<p>For very large inputs, precomputing field offsets can eliminate
-repeated prefix-free parsing.</p>
-<hr />
-<h2 id="final-summary"><strong>6.12 Final summary</strong></h2>
-<p>This unified design achieves several important goals:</p>
-<ol type="1">
-<li><strong>Zero-copy operations</strong> — Identity and projection work
-directly on serialized data</li>
-<li><strong>Demand-driven materialization</strong> — Memory allocation
-only when necessary</li>
-<li><strong>External type integration</strong> — Built-ins fit
-seamlessly into the execution model</li>
-<li><strong>Parallel execution</strong> — Natural parallelization
-opportunities</li>
-<li><strong>Streaming capability</strong> — Process large inputs with
-bounded memory</li>
-</ol>
-<p>The decorated pointer model provides a clean abstraction that bridges
-the gap between the mathematical elegance of k’s type system and the
-performance requirements of real-world data processing.</p>
-<p><strong>Key insight</strong>: By treating serialized data as the
-primary representation and materialized structures as secondary
-optimization, we invert the traditional approach and achieve much better
-performance for sparse data access patterns.</p>
-<h3 id="hardware-optimized-encoding-summary"><strong>6.12.1
-Hardware-optimized encoding summary</strong></h3>
-<p>The final encoding strategy balances theoretical optimality with
-practical hardware constraints:</p>
-<p><strong>Trade-offs achieved</strong>:</p>
-<ul>
-<li><strong>Space efficiency</strong>: 80-90% of theoretical
-optimum</li>
-<li><strong>Decode performance</strong>: 5-10× faster than bit-level
-encoding<br />
-</li>
-<li><strong>Cache behavior</strong>: Excellent (word-aligned, sequential
-access)</li>
-<li><strong>SIMD compatibility</strong>: Yes (bulk discriminator
-processing)</li>
-<li><strong>Architecture agnostic</strong>: Optimized for x86-64 and
-ARM64</li>
-</ul>
-<p><strong>Performance characteristics</strong>:</p>
-<pre class="text"><code>Operation               Hardware-optimized    Bit-level optimal
-Field access           2-8 cycles           50-100 cycles
-Union matching         1-3 cycles           20-40 cycles  
-Memory bandwidth       95% theoretical      60% theoretical
-Cache miss ratio       &lt;5%                  &gt;25%</code></pre>
-<p><strong>Recommended for</strong>:</p>
-<ul>
-<li><strong>Production systems</strong> requiring high performance</li>
-<li><strong>Streaming applications</strong> with large data volumes</li>
-<li><strong>Mobile/embedded</strong> systems with limited CPU
-resources</li>
-<li><strong>SIMD-heavy workloads</strong> processing bulk data</li>
-</ul>
-<p>The hardware-optimized approach provides the best practical balance
-for real-world k implementations.</p>
-<hr />
-<hr />
-<h1 id="chapter-7-the-partial-function-abi">Chapter 7 — The Partial
-Function ABI</h1>
-<h2 id="purpose"><strong>7.1 Purpose</strong></h2>
-<p>The <strong>application binary interface (ABI)</strong> defines how
-partial functions in <code>k</code> 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.</p>
-<p>Every compiled <code>k</code> function receives a single argument (a
-value tree) and may either produce a result or remain undefined. The ABI
-provides a uniform way to express both outcomes.</p>
-<hr />
-<h2 id="function-result-representation"><strong>7.2 Function result
-representation</strong></h2>
-<p>The result of every function call is a pair of fields:</p>
-<div class="sourceCode" id="cb70"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb70-1"><a href="#cb70-1" aria-hidden="true" tabindex="-1"></a><span class="kw">struct</span> KOpt <span class="op">{</span></span>
-<span id="cb70-2"><a href="#cb70-2" aria-hidden="true" tabindex="-1"></a>    <span class="dt">bool</span> ok<span class="op">;</span>     <span class="co">// 1 if function is defined for the given input</span></span>
-<span id="cb70-3"><a href="#cb70-3" aria-hidden="true" tabindex="-1"></a>    <span class="kw">struct</span> KNode<span class="op">*</span> val<span class="op">;</span>  <span class="co">// valid only if ok == true</span></span>
-<span id="cb70-4"><a href="#cb70-4" aria-hidden="true" tabindex="-1"></a><span class="op">};</span></span></code></pre></div>
-<p>If <code>ok == 1</code>, the function succeeded and <code>val</code>
-points to the root node of the resulting value. If <code>ok == 0</code>,
-the function is undefined for the input, and <code>val</code> is
-meaningless.</p>
-<p>This structure carries both the success flag and the value pointer,
-allowing partiality to be expressed directly in generated code.</p>
-<hr />
-<h2 id="function-parameter-representation"><strong>7.3 Function
-parameter representation</strong></h2>
-<p>Each function takes exactly one parameter:</p>
-<div class="sourceCode" id="cb71"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb71-1"><a href="#cb71-1" aria-hidden="true" tabindex="-1"></a><span class="kw">struct</span> KNode<span class="op">*</span> input<span class="op">;</span></span></code></pre></div>
-<p>The parameter points to the root of the input value. Since all values
-are immutable, the function must not modify this structure.</p>
-<hr />
-<h2 id="calling-convention"><strong>7.4 Calling convention</strong></h2>
-<p>Every <code>k</code> function compiled to machine code follows this
-C-style signature:</p>
-<div class="sourceCode" id="cb72"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb72-1"><a href="#cb72-1" aria-hidden="true" tabindex="-1"></a><span class="kw">struct</span> KOpt k_function<span class="op">(</span><span class="kw">struct</span> KNode<span class="op">*</span> input<span class="op">);</span></span></code></pre></div>
-<p>The return value indicates success or failure. The convention is
-uniform for all functions, regardless of the specific types
-involved.</p>
-<hr />
-<h2 id="core-runtime-operations"><strong>7.5 Core runtime
-operations</strong></h2>
-<p>The runtime provides a small set of primitive functions implementing
-the fundamental operations of <code>k</code>:</p>
-<table>
-<colgroup>
-<col style="width: 32%" />
-<col style="width: 25%" />
-<col style="width: 42%" />
-</colgroup>
-<thead>
-<tr>
-<th>Operation</th>
-<th>Purpose</th>
-<th>Result</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td><code>k_project(input, label_id)</code></td>
-<td>projection <code>.label</code></td>
-<td>defined if the field or variant <code>label_id</code> exists</td>
-</tr>
-<tr>
-<td><code>k_make_product(state, children[], n)</code></td>
-<td>construct a product node</td>
-<td>always defined</td>
-</tr>
-<tr>
-<td><code>k_make_union(state, tag, child)</code></td>
-<td>construct a union node</td>
-<td>always defined</td>
-</tr>
-<tr>
-<td><code>k_fail()</code></td>
-<td>represent undefined result</td>
-<td>returns <code>{ ok = 0 }</code></td>
-</tr>
-<tr>
-<td><code>k_unit()</code></td>
-<td>return the constant unit node</td>
-<td>returns <code>{ ok = 1, val = &amp;unit_node }</code></td>
-</tr>
-</tbody>
-</table>
-<p>All user-defined functions can be compiled entirely in terms of these
-operations.</p>
-<hr />
-<h2 id="metadata-tables"><strong>7.6 Metadata tables</strong></h2>
-<p>To interpret or construct nodes correctly, the runtime holds constant
-tables derived from canonical type definitions:</p>
-<ul>
-<li><code>state_kind[state]</code> — <code>0</code> for product,
-<code>1</code> for union,</li>
-<li><code>state_arity[state]</code> — number of child fields for
-products (always 1 for unions),</li>
-<li><code>field_index[state][label_id]</code> — index of field in
-product (or <code>-1</code> if absent),</li>
-<li><code>variant_index[state][label_id]</code> — index of variant in
-union (or <code>-1</code> if absent).</li>
-</ul>
-<p>These tables are read-only and known at compile time for each
-canonical type.</p>
-<hr />
-<h2 id="example-projection"><strong>7.7 Example:
-projection</strong></h2>
-<p>To implement the projection <code>.x</code>:</p>
-<div class="sourceCode" id="cb73"><pre class="sourceCode c"><code class="sourceCode c"><span id="cb73-1"><a href="#cb73-1" aria-hidden="true" tabindex="-1"></a><span class="kw">struct</span> KOpt k_project_x<span class="op">(</span><span class="kw">struct</span> KNode<span class="op">*</span> input<span class="op">)</span> <span class="op">{</span></span>
-<span id="cb73-2"><a href="#cb73-2" aria-hidden="true" tabindex="-1"></a>    <span class="dt">int</span> state <span class="op">=</span> input<span class="op">-&gt;</span>state<span class="op">;</span></span>
-<span id="cb73-3"><a href="#cb73-3" aria-hidden="true" tabindex="-1"></a>    <span class="dt">int</span> kind  <span class="op">=</span> state_kind<span class="op">[</span>state<span class="op">];</span></span>
-<span id="cb73-4"><a href="#cb73-4" aria-hidden="true" tabindex="-1"></a></span>
-<span id="cb73-5"><a href="#cb73-5" aria-hidden="true" tabindex="-1"></a>    <span class="cf">if</span> <span class="op">(</span>kind <span class="op">==</span> PRODUCT<span class="op">)</span> <span class="op">{</span></span>
-<span id="cb73-6"><a href="#cb73-6" aria-hidden="true" tabindex="-1"></a>        <span class="dt">int</span> idx <span class="op">=</span> field_index<span class="op">[</span>state<span class="op">][</span><span class="st">&quot;x&quot;</span><span class="op">];</span></span>
-<span id="cb73-7"><a href="#cb73-7" aria-hidden="true" tabindex="-1"></a>        <span class="cf">if</span> <span class="op">(</span>idx <span class="op">&lt;</span> <span class="dv">0</span> <span class="op">||</span> idx <span class="op">&gt;=</span> input<span class="op">-&gt;</span>arity<span class="op">)</span></span>
-<span id="cb73-8"><a href="#cb73-8" aria-hidden="true" tabindex="-1"></a>            <span class="cf">return</span> <span class="op">(</span><span class="kw">struct</span> KOpt<span class="op">){</span><span class="dv">0</span><span class="op">,</span> NULL<span class="op">};</span></span>
-<span id="cb73-9"><a href="#cb73-9" aria-hidden="true" tabindex="-1"></a>        <span class="cf">return</span> <span class="op">(</span><span class="kw">struct</span> KOpt<span class="op">){</span><span class="dv">1</span><span class="op">,</span> input<span class="op">-&gt;</span>child<span class="op">[</span>idx<span class="op">]};</span></span>
-<span id="cb73-10"><a href="#cb73-10" aria-hidden="true" tabindex="-1"></a>    <span class="op">}</span></span>
-<span id="cb73-11"><a href="#cb73-11" aria-hidden="true" tabindex="-1"></a></span>
-<span id="cb73-12"><a href="#cb73-12" aria-hidden="true" tabindex="-1"></a>    <span class="cf">if</span> <span class="op">(</span>kind <span class="op">==</span> UNION<span class="op">)</span> <span class="op">{</span></span>
-<span id="cb73-13"><a href="#cb73-13" aria-hidden="true" tabindex="-1"></a>        <span class="dt">int</span> tag  <span class="op">=</span> variant_index<span class="op">[</span>state<span class="op">][</span><span class="st">&quot;x&quot;</span><span class="op">];</span></span>
-<span id="cb73-14"><a href="#cb73-14" aria-hidden="true" tabindex="-1"></a>        <span class="cf">if</span> <span class="op">(</span>tag <span class="op">&lt;</span> <span class="dv">0</span> <span class="op">||</span> input<span class="op">-&gt;</span>tag <span class="op">!=</span> tag<span class="op">)</span></span>
-<span id="cb73-15"><a href="#cb73-15" aria-hidden="true" tabindex="-1"></a>            <span class="cf">return</span> <span class="op">(</span><span class="kw">struct</span> KOpt<span class="op">){</span><span class="dv">0</span><span class="op">,</span> NULL<span class="op">};</span></span>
-<span id="cb73-16"><a href="#cb73-16" aria-hidden="true" tabindex="-1"></a>        <span class="cf">return</span> <span class="op">(</span><span class="kw">struct</span> KOpt<span class="op">){</span><span class="dv">1</span><span class="op">,</span> input<span class="op">-&gt;</span>child<span class="op">[</span><span class="dv">0</span><span class="op">]};</span></span>
-<span id="cb73-17"><a href="#cb73-17" aria-hidden="true" tabindex="-1"></a>    <span class="op">}</span></span>
-<span id="cb73-18"><a href="#cb73-18" aria-hidden="true" tabindex="-1"></a></span>
-<span id="cb73-19"><a href="#cb73-19" aria-hidden="true" tabindex="-1"></a>    <span class="cf">return</span> <span class="op">(</span><span class="kw">struct</span> KOpt<span class="op">){</span><span class="dv">0</span><span class="op">,</span> NULL<span class="op">};</span></span>
-<span id="cb73-20"><a href="#cb73-20" aria-hidden="true" tabindex="-1"></a><span class="op">}</span></span></code></pre></div>
-<p>This code demonstrates the generic principle: the projection is
-defined if and only if the input has a field or variant named
-<code>x</code>.</p>
-<hr />
-<h2 id="error-propagation"><strong>7.8 Error propagation</strong></h2>
-<p>When one function calls another, the success flag <code>ok</code>
-propagates forward. If a subcall returns <code>ok == 0</code>, the
-caller must return <code>{0, NULL}</code> immediately. This makes
-undefinedness explicit and local—no exceptions, no global flags.</p>
-<hr />
-<h2 id="summary-5"><strong>7.9 Summary</strong></h2>
-<ul>
-<li>Every function has the form <code>KOpt f(KNode*)</code>.</li>
-<li>Partiality is expressed by the <code>ok</code> flag.</li>
-<li>Runtime operations handle projection and construction.</li>
-<li>Metadata tables describe field positions and variant indices.</li>
-<li>By inspecting <code>arity</code>, <code>state</code>, and
-<code>tag</code>, the runtime can interpret any value correctly.</li>
-<li>This ABI ensures all generated and runtime functions can
-interoperate safely.</li>
-</ul>
-<hr />
-<hr />
-<h1 id="chapter-8-operational-semantics-and-execution">Chapter 8 —
-Operational Semantics and Execution</h1>
-<h2 id="purpose-1"><strong>8.1 Purpose</strong></h2>
-<p>The <strong>operational semantics</strong> of <code>k</code> describe
-how expressions are evaluated step by step on actual value trees. It
-defines when a function is <em>defined</em> for a particular input and
-what value it returns. All execution—interpretive or compiled—follows
-these rules.</p>
-<hr />
-<h2 id="evaluation-relation"><strong>8.2 Evaluation
-relation</strong></h2>
-<p>Evaluation is written as:</p>
-<pre class="text"><code>⟨ e , v ⟩ ⇓ r</code></pre>
-<p>meaning that expression <code>e</code> applied to value
-<code>v</code> yields result <code>r</code>. If <code>e</code> is
-undefined for <code>v</code>, the relation does not hold.</p>
-<p><code>r</code> is always a tree (or node) in memory, represented as
-described in Chapter 6. Undefined results are expressed by the absence
-of any rule that produces <code>r</code>.</p>
-<hr />
-<h2 id="rules-for-base-expressions"><strong>8.3 Rules for base
-expressions</strong></h2>
-<h3 id="identity"><strong>Identity</strong></h3>
-<pre class="text"><code>⟨ () , v ⟩ ⇓ v</code></pre>
-<p>The empty composition <code>()</code> returns its argument
-unchanged.</p>
-<h3 id="projection"><strong>Projection</strong></h3>
-<p>Let <code>label</code> be a field or variant name. If <code>v</code>
-has a child under <code>label</code>,</p>
-<pre class="text"><code>⟨ .label , v ⟩ ⇓ v.label</code></pre>
-<p>Otherwise the projection is undefined.</p>
-<h3 id="type-expression"><strong>Type expression</strong></h3>
-<p>For a type <code>T</code>,</p>
-<pre class="text"><code>⟨ $T , v ⟩ ⇓ v     if v ∈ T</code></pre>
-<p>and undefined otherwise. Type expressions thus act as identity
-functions restricted to their type.</p>
-<hr />
-<h2 id="rules-for-composition"><strong>8.4 Rules for
-composition</strong></h2>
-<h3 id="sequential-composition"><strong>Sequential
-composition</strong></h3>
-<pre class="text"><code>⟨ (f g) , v ⟩ ⇓ r</code></pre>
-<p>if there exists <code>u</code> such that <code>⟨ f , v ⟩ ⇓ u</code>
-and <code>⟨ g , u ⟩ ⇓ r</code>.</p>
-<p>If either step is undefined, the composition is undefined. Because
-composition is associative,</p>
-<pre class="text"><code>(f (g h))  ≡  ((f g) h)  ≡  (f g h)</code></pre>
-<p>Parentheses are needed only for <code>()</code>.</p>
-<hr />
-<h2 id="rules-for-product-composition"><strong>8.5 Rules for product
-composition</strong></h2>
-<pre class="text"><code>⟨ { f₁ l₁ , f₂ l₂ , … , fₙ lₙ } , v ⟩ ⇓ { r₁ l₁ , r₂ l₂ , … , rₙ lₙ }</code></pre>
-<p>if and only if all subfunctions <code>fᵢ</code> are defined on
-<code>v</code> and yield <code>rᵢ</code>. If any subfunction is
-undefined, the whole product composition is undefined.</p>
-<p>A product composition constructs a new product node; each result
-<code>rᵢ</code> becomes one child in canonical field order.</p>
-<hr />
-<h2 id="rules-for-union-composition"><strong>8.6 Rules for union
-composition</strong></h2>
-<pre class="text"><code>⟨ &lt; f₁ , f₂ , … , fₙ &gt; , v ⟩ ⇓ rⱼ</code></pre>
-<p>if there exists the smallest index <code>j</code> such that
-<code>⟨ fⱼ , v ⟩ ⇓ rⱼ</code>.</p>
-<p>If no subfunction is defined, the union composition is undefined.</p>
-<hr />
-<h2 id="rules-for-filters"><strong>8.7 Rules for filters</strong></h2>
-<p>If a filter <code>F</code> matches a single type <code>T</code></p>
-<pre class="text"><code>⟨ ?F , v ⟩ ⇓ ⟨ $T , v ⟩ </code></pre>
-<p>otherwise it is an identity</p>
-<pre class="text"><code>⟨ ?F , v ⟩ ⇓ v</code></pre>
-<p>Filters therefore act as compile time annotations for type checking
-only. They are ignored at run-time, unless they lead to fully typed
-expressions (i.e., can be replaced by a type).</p>
-<hr />
-<h2 id="evaluation-order"><strong>8.8 Evaluation order</strong></h2>
-<p>Evaluation proceeds left to right. In products, all subfunctions
-receive the same input; in unions, later functions are evaluated only if
-earlier ones fail.</p>
-<p>The semantics are deterministic: for any given input, at most one
-result tree can be produced.</p>
-<hr />
-<h2 id="example-1"><strong>8.9 Example</strong></h2>
-<p>Given:</p>
-<pre class="k-lang"><code>$bool = &lt; {} true, {} false &gt;;
-neg = $bool &lt; .true {{ } false}, .false {{ } true} &gt; $bool;</code></pre>
-<p>and input value <code>{ {} true }</code> of type <code>bool</code>,
-evaluation steps are:</p>
-<ol type="1">
-<li><code>⟨ $bool , { {} true } ⟩ ⇓ { {} true }</code></li>
-<li><code>⟨ &lt; .true {{ } false}, .false {{ } true} &gt; , { {} true } ⟩ ⇓ {{ } false}</code></li>
-<li><code>⟨ $bool , {{ } false} ⟩ ⇓ {{ } false}</code></li>
-</ol>
-<p>Final result: <code>{{ } false}</code>. If the input were of another
-type, step 1 would be undefined.</p>
-<hr />
-<h2 id="implementation-correspondence"><strong>8.10 Implementation
-correspondence</strong></h2>
-<p>The evaluation rules map directly onto the runtime ABI:</p>
-<table>
-<thead>
-<tr>
-<th>Semantic rule</th>
-<th>Runtime operation</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td>Projection</td>
-<td><code>k_project</code></td>
-</tr>
-<tr>
-<td>Product composition</td>
-<td>multiple subcalls + <code>k_make_product</code></td>
-</tr>
-<tr>
-<td>Union composition</td>
-<td>sequential subcalls with early return</td>
-</tr>
-<tr>
-<td>Type</td>
-<td>runtime check of <code>state</code></td>
-</tr>
-<tr>
-<td>Composition</td>
-<td>function call chain</td>
-</tr>
-</tbody>
-</table>
-<p>In compiled form, the <code>ok</code> flag of <code>KOpt</code>
-represents whether a rule applies; the node pointer represents the
-result value.</p>
-<hr />
-<h2 id="summary-6"><strong>8.11 Summary</strong></h2>
-<ul>
-<li>Execution follows deterministic, left-to-right rules.</li>
-<li>All expressions denote partial functions on value trees.</li>
-<li>Type expressions act as restricted identities.</li>
-<li>Composition is associative; undefined propagates automatically.</li>
-<li>Runtime semantics match the formal evaluation relation exactly.</li>
-</ul>
-<hr />
-<hr />
-<h1 id="chapter-9-compiler-architecture">Chapter 9 — Compiler
-Architecture</h1>
-<h2 id="what-the-compiler-does"><strong>9.1 What the compiler
-does</strong></h2>
-<p>A <em>compiler</em> for the <code>k</code> language is a program that
-reads another program (written in <code>k</code>) and produces a
-lower-level version of it. The lower-level version can then be executed
-efficiently by a computer.</p>
-<p>For <code>k</code>, the compiler’s task is simple in concept:</p>
-<ol type="1">
-<li><strong>Read</strong> the definitions of types and functions.</li>
-<li><strong>Understand</strong> their structure and the relationships
-between them.</li>
-<li><strong>Translate</strong> them into equivalent instructions that
-follow the runtime conventions described in Chapters 6–8.</li>
-</ol>
-<p>The compiler must ensure that every function in the source program
-becomes a machine-level function that behaves in exactly the same way:
-it takes a value as input, may or may not be defined for it, and, if
-defined, produces another value.</p>
-<hr />
-<h2 id="the-main-stages"><strong>9.2 The main stages</strong></h2>
-<p>A <code>k</code> compiler is organized as a sequence of well-defined
-stages. Each stage transforms one representation of the program into
-another, simpler one.</p>
-<ol type="1">
-<li><p><strong>Reading and parsing</strong> — The compiler converts the
-source text into a tree of syntactic objects. This tree is called the
-<em>abstract syntax tree</em> (AST). It records the structure of
-expressions such as <code>{ .x a, .y b }</code> or
-<code>&lt; .x, .y &gt;</code>.</p></li>
-<li><p><strong>Type analysis and normalization</strong> — The compiler
-expands type names, checks their correctness, and replaces all filters
-and meta-variables by concrete type information, following the procedure
-from Chapter 5. The result is a fully typed AST.</p></li>
-<li><p><strong>Preparation for execution</strong> — The compiler builds
-a <em>type table</em> for all canonical type states (C0, C1, …). For
-each type, it records whether it is a product or a union and the number
-and names of its fields or variants. These tables become the metadata
-used at runtime.</p></li>
-<li><p><strong>Code generation</strong> — Finally, the compiler walks
-through the typed AST and produces an equivalent description in a
-lower-level form that follows the runtime conventions: functions
-returning a success flag and a value pointer. This form can be expressed
-directly in C or in the <em>LLVM intermediate representation</em>, which
-is a platform-independent format understood by many compilers.</p></li>
-</ol>
-<hr />
-<h2 id="internal-structure"><strong>9.3 Internal structure</strong></h2>
-<p>A minimal compiler can be viewed as three connected modules:</p>
-<ul>
-<li><strong>Front end</strong> — reads source code, builds the AST,
-performs type analysis.</li>
-<li><strong>Middle</strong> — resolves all references, normalizes types,
-and simplifies expressions.</li>
-<li><strong>Back end</strong> — produces the executable form.</li>
-</ul>
-<p>Although these terms are traditional, the distinction is simple: the
-front end <em>understands</em> the program, the back end <em>emits</em>
-it, and the middle part connects the two.</p>
-<hr />
-<h2 id="data-kept-by-the-compiler"><strong>9.4 Data kept by the
-compiler</strong></h2>
-<p>During translation the compiler maintains several tables:</p>
-<table>
-<colgroup>
-<col style="width: 21%" />
-<col style="width: 78%" />
-</colgroup>
-<thead>
-<tr>
-<th>Name</th>
-<th>Purpose</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td><strong>Type table</strong></td>
-<td>Maps type names to canonical forms and assigns numeric state
-IDs.</td>
-</tr>
-<tr>
-<td><strong>Field table</strong></td>
-<td>For each product type, records the order and index of its
-fields.</td>
-</tr>
-<tr>
-<td><strong>Variant table</strong></td>
-<td>For each union type, records the tags and their numeric
-indices.</td>
-</tr>
-<tr>
-<td><strong>Function table</strong></td>
-<td>Associates function names with their input and output types.</td>
-</tr>
-</tbody>
-</table>
-<p>These tables ensure that generated code can find fields and variants
-by number rather than by name, which simplifies execution.</p>
-<hr />
-<h2 id="example-of-transformation"><strong>9.5 Example of
-transformation</strong></h2>
-<p>Consider a simple k program:</p>
-<pre class="k-lang"><code>$bool = &lt; {} true, {} false &gt;;
-neg = $bool &lt; /true | false, /false | true &gt; $bool;</code></pre>
-<ol type="1">
-<li><p><strong>Parsing:</strong> The compiler recognizes a type
-definition <code>$bool</code> and a function <code>neg</code>.</p></li>
-<li><p><strong>Type analysis:</strong> Both the input and output of
-<code>neg</code> are of type <code>bool</code>.</p></li>
-<li><p><strong>Internal representation:</strong> The compiler constructs
-an internal tree describing that
-<code>&lt; /true f₁, /false f₂ &gt;</code> means: try the projection
-<code>/true</code>, then <code>/false</code>, each producing a constant
-value.</p></li>
-<li><p><strong>Generated form:</strong> In the target language,
-<code>neg</code> becomes a small function that:</p>
-<ul>
-<li>calls <code>k_project</code> to check which variant the input
-has,</li>
-<li>creates a new node with the opposite variant using
-<code>k_make_union</code>, and</li>
-<li>returns the result with <code>ok = 1</code>.</li>
-</ul></li>
-</ol>
-<p>This sequence of steps is fully automatic and follows directly from
-the semantic rules in Chapter 8.</p>
-<hr />
-<h2 id="intermediate-representation"><strong>9.6 Intermediate
-representation</strong></h2>
-<p>Before producing final code, many compilers use an <em>intermediate
-representation</em> (IR). It is a language designed to be easy to
-generate and easy to translate further into real machine code. For
-<code>k</code>, the IR mirrors the structure of partial functions:</p>
-<table>
-<thead>
-<tr>
-<th>Concept in k</th>
-<th>IR operation</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td>Projection <code>.x</code> ‘/x’</td>
-<td><code>PROJECT label_id</code></td>
-</tr>
-<tr>
-<td>Composition <code>(f g)</code></td>
-<td><code>CALL f; CALL g</code></td>
-</tr>
-<tr>
-<td>Union <code>&lt;f,g&gt;</code></td>
-<td><code>TRY f; IF undefined THEN TRY g</code></td>
-</tr>
-<tr>
-<td>Product <code>{.x f, .y g}</code></td>
-<td><code>PRODUCT_CALL (f, g); COMBINE</code></td>
-</tr>
-<tr>
-<td>Type restriction <code>$T</code></td>
-<td><code>CHECK_TYPE state_id</code></td>
-</tr>
-</tbody>
-</table>
-<p>The compiler converts each AST node into one or more IR instructions.
-The <code>PRODUCT_CALL(f, g)</code> instruction is a higher-level
-concept that implies applying both <code>f</code> and <code>g</code> to
-the same input value. The low-level implementation of this would use
-stack operations to duplicate the input, but the IR itself remains more
-abstract. Later, these instructions are translated into LLVM or C code
-using the runtime ABI.</p>
-<hr />
-<h2 id="linking-with-the-runtime"><strong>9.7 Linking with the
-runtime</strong></h2>
-<p>The generated code does not contain memory allocation or type tables
-itself. Instead, it relies on the runtime library (<code>krt</code>),
-which provides:</p>
-<ul>
-<li>functions such as <code>k_project</code> and
-<code>k_make_union</code>,</li>
-<li>metadata tables for each canonical type, and</li>
-<li>the unit value <code>{}</code> shared by all programs.</li>
-</ul>
-<p>When the compiler finishes, it outputs a text file in the target
-language plus references to this runtime library. The two together form
-an executable program.</p>
-<hr />
-<h2 id="simplicity-of-the-model"><strong>9.8 Simplicity of the
-model</strong></h2>
-<p>Because every expression in <code>k</code> takes exactly one input
-and may return one output or be undefined, the compiler never has to
-deal with variable environments, loops, or side effects. This makes the
-structure of the generated program very regular:</p>
-<pre class="text"><code>input → [series of calls and checks] → output or undefined</code></pre>
-<p>Each compiled function is independent and stateless. This regularity
-is what allows <code>k</code> to map cleanly to low-level code.</p>
-<hr />
-<h2 id="summary-7"><strong>9.9 Summary</strong></h2>
-<ul>
-<li>The compiler transforms <code>k</code> programs into executable form
-through a sequence of simple, deterministic steps.</li>
-<li>Type information and structure are resolved before code
-generation.</li>
-<li>All generated functions follow the same calling convention
-(<code>ok</code>, <code>val</code>).</li>
-<li>The runtime library provides the shared operations needed by every
-program.</li>
-<li>The entire process mirrors the formal semantics defined earlier but
-expresses it as concrete machine operations.</li>
-</ul>
-<hr />
-<hr />
-<h1 id="chapter-10-from-ast-to-intermediate-representation">Chapter 10 —
-From AST to Intermediate Representation</h1>
-<h2 id="the-purpose-of-an-intermediate-form"><strong>10.1 The purpose of
-an intermediate form</strong></h2>
-<p>The abstract syntax tree (AST) of a <code>k</code> program directly
-reflects how the source code was written. It is easy to read but not
-convenient for generating machine code. Before code can be produced, the
-compiler rewrites this tree into a <strong>simpler, regular
-structure</strong> called the <em>intermediate representation</em>
-(IR).</p>
-<p>The IR is close to what the machine will execute, but it still looks
-like a structured program rather than raw binary instructions. Each node
-in the IR corresponds to a single, well-defined operation such as
-<em>project a field</em>, <em>apply a function</em>, or <em>combine
-results</em>.</p>
-<p>Using an intermediate form helps in three ways:</p>
-<ol type="1">
-<li>It separates understanding of the language from machine
-details.</li>
-<li>It allows the compiler to verify that every function is well
-formed.</li>
-<li>It provides a uniform surface for optimization and for later
-translation into C or LLVM.</li>
-</ol>
-<hr />
-<h2 id="shape-of-the-intermediate-representation"><strong>10.2 Shape of
-the intermediate representation</strong></h2>
-<p>Each IR instruction corresponds to one semantic rule from Chapter 8.
-The IR does not need to represent filters or meta-variables, since those
-are resolved earlier. Only concrete actions remain.</p>
-<table>
-<colgroup>
-<col style="width: 31%" />
-<col style="width: 68%" />
-</colgroup>
-<thead>
-<tr>
-<th>Operation</th>
-<th>Meaning</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td><strong>PROJECT label_id</strong></td>
-<td>Apply <code>.label</code> to the input value.</td>
-</tr>
-<tr>
-<td><strong>TYPECHECK state_id</strong></td>
-<td>Accept the input only if its root has the given canonical
-state.</td>
-</tr>
-<tr>
-<td><strong>CALL function_id</strong></td>
-<td>Invoke another function following the ABI.</td>
-</tr>
-<tr>
-<td><strong>UNION [f₁, f₂, …]</strong></td>
-<td>Try several functions in order until one succeeds.</td>
-</tr>
-<tr>
-<td><strong>PRODUCT [l₁=f₁, l₂=f₂, …]</strong></td>
-<td>Apply each function to the same input and combine results.</td>
-</tr>
-<tr>
-<td><strong>FAIL</strong></td>
-<td>Always undefined.</td>
-</tr>
-<tr>
-<td><strong>SEQ [f₁, f₂, …]</strong></td>
-<td>Apply functions in sequence (composition).</td>
-</tr>
-</tbody>
-</table>
-<p>Each function in the program becomes a small list or tree of such IR
-instructions.</p>
-<hr />
-<h2 id="example-2"><strong>10.3 Example</strong></h2>
-<p>Source program:</p>
-<pre class="k-lang"><code>$bool = &lt; {} true, {} false &gt;;
-neg = $bool &lt; .true {{ } false}, .false {{ } true} &gt; $bool;</code></pre>
-<p>The IR for <code>neg</code> can be written informally as:</p>
-<pre class="text"><code>neg:
-  TYPECHECK bool
-  UNION [
-    SEQ [ PROJECT true, CONST false ],
-    SEQ [ PROJECT false, CONST true ]
-  ]
-  TYPECHECK bool</code></pre>
-<p>This IR expresses the same logic as the source: check the type, then
-try the first projection <code>.true</code>, otherwise the second, and
-finally ensure the result is again of type <code>$bool</code>.</p>
-<hr />
-<h2 id="relation-to-evaluation"><strong>10.4 Relation to
-evaluation</strong></h2>
-<p>Every IR operation corresponds to a runtime action:</p>
-<table>
-<thead>
-<tr>
-<th>IR operation</th>
-<th>Runtime function or behavior</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td>PROJECT</td>
-<td><code>k_project(input, label_id)</code></td>
-</tr>
-<tr>
-<td>TYPECHECK</td>
-<td>verify <code>input-&gt;state == state_id</code></td>
-</tr>
-<tr>
-<td>CALL</td>
-<td>call another generated function</td>
-</tr>
-<tr>
-<td>UNION</td>
-<td>sequential <code>if</code>–<code>else</code> test on success
-flags</td>
-</tr>
-<tr>
-<td>PRODUCT</td>
-<td>multiple subcalls + <code>k_make_product</code></td>
-</tr>
-<tr>
-<td>FAIL</td>
-<td>return <code>{ ok = 0 }</code> immediately</td>
-</tr>
-<tr>
-<td>SEQ</td>
-<td>connect the output of one step as input to the next</td>
-</tr>
-</tbody>
-</table>
-<p>By describing computation in these terms, the compiler can generate
-executable code simply by replacing each IR instruction with its runtime
-equivalent.</p>
-<hr />
-<h2 id="building-the-ir"><strong>10.5 Building the IR</strong></h2>
-<p>The process of converting the AST to IR follows a recursive
-pattern:</p>
-<ol type="1">
-<li><strong>Projections</strong> become single instructions
-<code>PROJECT</code>.</li>
-<li><strong>Compositions</strong> <code>(f g h)</code> become a
-<code>SEQ</code> list of their components.</li>
-<li><strong>Unions</strong> <code>&lt;f,g&gt;</code> become a
-<code>UNION</code> list.</li>
-<li><strong>Products</strong> <code>{f l₁, g l₂}</code> become a
-<code>PRODUCT</code> list with labeled entries.</li>
-<li><strong>Type expressions</strong> <code>$T</code> become
-<code>TYPECHECK</code> instructions.</li>
-<li><strong>Filters</strong> disappear; their meaning is already
-captured by typechecks.</li>
-</ol>
-<p>Each transformation step produces IR nodes with fixed behavior and
-explicit order.</p>
-<hr />
-<h2 id="verifying-the-ir"><strong>10.6 Verifying the IR</strong></h2>
-<p>Because k programs are defined by simple composition, a small set of
-checks ensures correctness:</p>
-<ol type="1">
-<li>Each <code>UNION</code> list must have at least one element.</li>
-<li>Every <code>PROJECT</code> must have a valid label.</li>
-<li>Input and output states of consecutive steps must match.</li>
-<li>A function must end in an operation that produces a result
-(<code>PROJECT</code>, <code>CALL</code>, or combination).</li>
-</ol>
-<p>After verification, the IR is guaranteed to represent a valid partial
-function according to the semantics in Chapter 8.</p>
-<hr />
-<h2 id="intermediate-form-as-a-small-language"><strong>10.7 Intermediate
-form as a small language</strong></h2>
-<p>The IR can be viewed as a minimal language on its own. It has:</p>
-<ul>
-<li>one data type (<code>KNode*</code>),</li>
-<li>one universal value format (trees),</li>
-<li>and a fixed set of operators.</li>
-</ul>
-<p>Its execution model is the same as the runtime ABI. This means an
-interpreter for the IR can serve as a reference implementation of the k
-semantics before any machine code generation is added.</p>
-<hr />
-<h2 id="example-product-composition"><strong>10.8 Example: product
-composition</strong></h2>
-<p>For input function <code>{ .x a, .y b }</code>, the IR is:</p>
-<pre class="text"><code>PRODUCT [
-  a = PROJECT x,
-  b = PROJECT y
-]</code></pre>
-<p>The runtime sequence is:</p>
-<ol type="1">
-<li>Apply each projection.</li>
-<li>If both succeed, build a new node with two children in order
-<code>(a,b)</code>.</li>
-</ol>
-<p>This pattern covers all record-building operations in the
-language.</p>
-<hr />
-<h2 id="why-this-representation-is-useful"><strong>10.9 Why this
-representation is useful</strong></h2>
-<p>This intermediate form provides three practical benefits:</p>
-<ol type="1">
-<li><strong>Clarity</strong> – every step is explicit and local.</li>
-<li><strong>Verifiability</strong> – type consistency and definedness
-can be checked mechanically.</li>
-<li><strong>Flexibility</strong> – the same IR can be translated to many
-targets (LLVM IR, C, or even interpreted directly).</li>
-</ol>
-<p>Because of these advantages, most compilers for declarative languages
-use an intermediate form of this kind.</p>
-<hr />
-<h2 id="summary-8"><strong>10.10 Summary</strong></h2>
-<ul>
-<li>The abstract syntax tree is rewritten into a simpler,
-machine-oriented form.</li>
-<li>Each IR instruction represents one operation defined by the
-<code>k</code> semantics.</li>
-<li>Type and filter information appear as explicit checks.</li>
-<li>The IR is easy to verify and to translate into executable code.</li>
-<li>The IR can also serve as a precise description of how <code>k</code>
-functions behave step by step.</li>
-</ul>
-<hr />
-<hr />
-<h1 id="chapter-11-llvm-basics">Chapter 11 — LLVM Basics</h1>
-<h2 id="purpose-2"><strong>11.1 Purpose</strong></h2>
-<p>The previous chapters described how a <code>k</code> program can be
-reduced to a small set of intermediate operations. To execute these
-operations efficiently, the compiler must translate them into an actual
-machine language. Instead of generating raw machine code directly, we
-use a common intermediate format called <strong>LLVM IR</strong> (LLVM
-<em>Intermediate Representation</em>).</p>
-<p>LLVM IR is a low-level, strongly typed language that resembles a
-simplified form of assembly. It can be read and written as text,
-analyzed, optimized, and compiled to machine code for almost any
-processor. For the compiler writer, it provides a bridge between
-high-level language semantics and executable programs.</p>
-<hr />
-<h2 id="structure-of-an-llvm-program"><strong>11.2 Structure of an LLVM
-program</strong></h2>
-<p>An LLVM program consists of <strong>global definitions</strong> and
-<strong>functions</strong>.</p>
-<ul>
-<li><p><em>Global definitions</em> describe data structures shared
-between functions. In the <code>k</code> compiler, this includes the
-runtime metadata tables and constant nodes such as
-<code>{}</code>.</p></li>
-<li><p><em>Functions</em> contain sequences of instructions grouped into
-<strong>basic blocks</strong>. A basic block is a straight-line segment
-of code with no branches except at the end. Branches connect blocks,
-forming a control-flow graph.</p></li>
-</ul>
-<p>Each instruction produces a new value; values are immutable once
-created. This property is called <em>single static assignment</em>
-(SSA).</p>
-<hr />
-<h2 id="data-types"><strong>11.3 Data types</strong></h2>
-<p>LLVM provides several primitive types. Only a few are required for
-the <code>k</code> compiler:</p>
-<table>
-<thead>
-<tr>
-<th>LLVM type</th>
-<th>Meaning</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td><code>i1</code></td>
-<td>one-bit boolean (used for success flag)</td>
-</tr>
-<tr>
-<td><code>i32</code></td>
-<td>32-bit integer (used for state IDs, indices, tags)</td>
-</tr>
-<tr>
-<td><code>ptr</code> or <code>%T*</code></td>
-<td>pointer to data in memory</td>
-</tr>
-<tr>
-<td><code>%struct {...}</code></td>
-<td>user-defined record (used for <code>KNode</code> and
-<code>KOpt</code>)</td>
-</tr>
-</tbody>
-</table>
-<p>The main structures used by generated code are:</p>
-<div class="sourceCode" id="cb90"><pre
-class="sourceCode llvm"><code class="sourceCode llvm"><span id="cb90-1"><a href="#cb90-1" aria-hidden="true" tabindex="-1"></a><span class="fu">%KNode</span> = <span class="kw">type</span> { <span class="dt">i32</span>, <span class="dt">i32</span>, <span class="dt">i32</span>, [<span class="dv">0</span> x <span class="fu">%KNode</span>*] }</span>
-<span id="cb90-2"><a href="#cb90-2" aria-hidden="true" tabindex="-1"></a><span class="fu">%KVal</span>  = <span class="kw">type</span> { <span class="fu">%KNode</span>* }</span>
-<span id="cb90-3"><a href="#cb90-3" aria-hidden="true" tabindex="-1"></a><span class="fu">%KOpt</span>  = <span class="kw">type</span> { <span class="dt">i1</span>, <span class="fu">%KVal</span> }</span></code></pre></div>
-<p><code>%KNode</code> represents one tree node in memory;
-<code>%KOpt</code> represents the result of a partial function, with an
-<code>ok</code> flag and a value pointer.</p>
-<hr />
-<h2 id="function-signatures"><strong>11.4 Function
-signatures</strong></h2>
-<p>Every compiled <code>k</code> function is translated into one LLVM
-function with the following signature:</p>
-<div class="sourceCode" id="cb91"><pre
-class="sourceCode llvm"><code class="sourceCode llvm"><span id="cb91-1"><a href="#cb91-1" aria-hidden="true" tabindex="-1"></a><span class="kw">define</span> <span class="fu">%KOpt</span> <span class="fu">@f_name</span>(<span class="fu">%KVal</span> <span class="fu">%in</span>) { ... }</span></code></pre></div>
-<p>The function takes a single argument <code>%in</code>, which holds
-the pointer to the input value. It returns a <code>%KOpt</code>
-structure containing the success flag and the resulting value.</p>
-<p>This mirrors the runtime ABI introduced in Chapter 7. By using the
-same layout, all functions can call each other without conversions.</p>
-<hr />
-<h2 id="control-flow"><strong>11.5 Control flow</strong></h2>
-<p>LLVM IR uses <strong>conditional branches</strong> to express choices
-and <strong>phi-nodes</strong> to merge results from different
-paths.</p>
-<p>A typical pattern for union composition <code>&lt;f,g&gt;</code>
-is:</p>
-<div class="sourceCode" id="cb92"><pre
-class="sourceCode llvm"><code class="sourceCode llvm"><span id="cb92-1"><a href="#cb92-1" aria-hidden="true" tabindex="-1"></a><span class="fu">%r1</span> = <span class="kw">call</span> <span class="fu">%KOpt</span> <span class="fu">@f</span>(<span class="fu">%in</span>)</span>
-<span id="cb92-2"><a href="#cb92-2" aria-hidden="true" tabindex="-1"></a><span class="fu">%ok1</span> = <span class="kw">extractvalue</span> <span class="fu">%KOpt</span> <span class="fu">%r1</span>, <span class="dv">0</span></span>
-<span id="cb92-3"><a href="#cb92-3" aria-hidden="true" tabindex="-1"></a><span class="kw">br</span> <span class="dt">i1</span> <span class="fu">%ok1</span>, <span class="dt">label</span> <span class="fu">%success</span>, <span class="dt">label</span> <span class="fu">%try_next</span></span>
-<span id="cb92-4"><a href="#cb92-4" aria-hidden="true" tabindex="-1"></a></span>
-<span id="cb92-5"><a href="#cb92-5" aria-hidden="true" tabindex="-1"></a><span class="fu">try_next:</span></span>
-<span id="cb92-6"><a href="#cb92-6" aria-hidden="true" tabindex="-1"></a><span class="fu">%r2</span> = <span class="kw">call</span> <span class="fu">%KOpt</span> <span class="fu">@g</span>(<span class="fu">%in</span>)</span>
-<span id="cb92-7"><a href="#cb92-7" aria-hidden="true" tabindex="-1"></a><span class="kw">br</span> <span class="dt">label</span> <span class="fu">%merge</span></span>
-<span id="cb92-8"><a href="#cb92-8" aria-hidden="true" tabindex="-1"></a></span>
-<span id="cb92-9"><a href="#cb92-9" aria-hidden="true" tabindex="-1"></a><span class="fu">success:</span></span>
-<span id="cb92-10"><a href="#cb92-10" aria-hidden="true" tabindex="-1"></a><span class="kw">br</span> <span class="dt">label</span> <span class="fu">%merge</span></span>
-<span id="cb92-11"><a href="#cb92-11" aria-hidden="true" tabindex="-1"></a></span>
-<span id="cb92-12"><a href="#cb92-12" aria-hidden="true" tabindex="-1"></a><span class="fu">merge:</span></span>
-<span id="cb92-13"><a href="#cb92-13" aria-hidden="true" tabindex="-1"></a><span class="fu">%res</span> = <span class="kw">phi</span> <span class="fu">%KOpt</span> [ <span class="fu">%r1</span>, <span class="fu">%success</span> ], [ <span class="fu">%r2</span>, <span class="fu">%try_next</span> ]</span>
-<span id="cb92-14"><a href="#cb92-14" aria-hidden="true" tabindex="-1"></a><span class="kw">ret</span> <span class="fu">%res</span></span></code></pre></div>
-<p>This code means: try <code>f</code>; if it succeeds, use that result;
-otherwise, try <code>g</code>. The <code>phi</code> instruction chooses
-between values coming from different blocks.</p>
-<hr />
-<h2 id="memory-operations"><strong>11.6 Memory operations</strong></h2>
-<p>Most functions in k do not modify existing nodes; they create new
-ones. Node creation is implemented as calls to runtime functions:</p>
-<div class="sourceCode" id="cb93"><pre
-class="sourceCode llvm"><code class="sourceCode llvm"><span id="cb93-1"><a href="#cb93-1" aria-hidden="true" tabindex="-1"></a><span class="kw">declare</span> <span class="fu">%KVal</span> <span class="fu">@k_make_product</span>(<span class="dt">i32</span> <span class="fu">%state</span>, <span class="dt">i32</span> <span class="fu">%n</span>, <span class="fu">%KVal</span>* <span class="fu">%children</span>)</span>
-<span id="cb93-2"><a href="#cb93-2" aria-hidden="true" tabindex="-1"></a><span class="kw">declare</span> <span class="fu">%KVal</span> <span class="fu">@k_make_union</span>(<span class="dt">i32</span> <span class="fu">%state</span>, <span class="dt">i32</span> <span class="fu">%tag</span>, <span class="fu">%KVal</span> <span class="fu">%child</span>)</span></code></pre></div>
-<p>These calls allocate new immutable nodes. The compiler provides the
-correct <code>state</code>, <code>tag</code>, and child references
-according to the canonical type.</p>
-<hr />
-<h2 id="constants-1"><strong>11.7 Constants</strong></h2>
-<p>Constant values such as <code>{{} true}</code> are represented as
-global variables in LLVM:</p>
-<div class="sourceCode" id="cb94"><pre
-class="sourceCode llvm"><code class="sourceCode llvm"><span id="cb94-1"><a href="#cb94-1" aria-hidden="true" tabindex="-1"></a><span class="fu">@unit_node</span>  = <span class="kw">constant</span> <span class="fu">%KNode</span> { <span class="dv">1</span>, -<span class="dv">1</span>, <span class="dv">0</span>, [] }</span>
-<span id="cb94-2"><a href="#cb94-2" aria-hidden="true" tabindex="-1"></a><span class="fu">@true_node</span>  = <span class="kw">constant</span> <span class="fu">%KNode</span> { <span class="dv">0</span>, <span class="dv">0</span>, <span class="dv">1</span>, [<span class="fu">@unit_node</span>] }</span>
-<span id="cb94-3"><a href="#cb94-3" aria-hidden="true" tabindex="-1"></a><span class="fu">@false_node</span> = <span class="kw">constant</span> <span class="fu">%KNode</span> { <span class="dv">0</span>, <span class="dv">1</span>, <span class="dv">1</span>, [<span class="fu">@unit_node</span>] }</span></code></pre></div>
-<p>Each constant is a fully formed node with fixed fields. When a
-constant function is called, the compiler returns a pointer to the
-corresponding global node.</p>
-<hr />
-<h2 id="from-ir-to-llvm"><strong>11.8 From IR to LLVM</strong></h2>
-<p>Translating the compiler’s intermediate form (Chapter 10) into LLVM
-is mechanical:</p>
-<table>
-<colgroup>
-<col style="width: 18%" />
-<col style="width: 81%" />
-</colgroup>
-<thead>
-<tr>
-<th>IR operation</th>
-<th>LLVM translation</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td><code>PROJECT</code></td>
-<td>call <code>@k_project</code></td>
-</tr>
-<tr>
-<td><code>TYPECHECK</code></td>
-<td>compare <code>input-&gt;state</code> with constant</td>
-</tr>
-<tr>
-<td><code>CONST</code></td>
-<td>return constant node</td>
-</tr>
-<tr>
-<td><code>PRODUCT</code></td>
-<td>evaluate subcalls, check flags, call
-<code>@k_make_product</code></td>
-</tr>
-<tr>
-<td><code>UNION</code></td>
-<td>generate branching structure as above</td>
-</tr>
-<tr>
-<td><code>SEQ</code></td>
-<td>chain calls: feed output to next input</td>
-</tr>
-<tr>
-<td><code>FAIL</code></td>
-<td>return <code>%KOpt { 0, undef }</code></td>
-</tr>
-</tbody>
-</table>
-<p>These mappings produce correct, low-level code while remaining
-faithful to the language semantics.</p>
-<hr />
-<h2 id="example-3"><strong>11.9 Example</strong></h2>
-<p>For the function <code>neg</code> from earlier:</p>
-<pre class="k-lang"><code>$bool = &lt; {} true, {} false &gt;;
-neg = $bool &lt; .true {{ } false}, .false {{ } true} &gt; $bool;</code></pre>
-<p>The simplified LLVM version may look as follows (comments added):</p>
-<div class="sourceCode" id="cb96"><pre
-class="sourceCode llvm"><code class="sourceCode llvm"><span id="cb96-1"><a href="#cb96-1" aria-hidden="true" tabindex="-1"></a><span class="kw">define</span> <span class="fu">%KOpt</span> <span class="fu">@neg</span>(<span class="fu">%KVal</span> <span class="fu">%in</span>) {</span>
-<span id="cb96-2"><a href="#cb96-2" aria-hidden="true" tabindex="-1"></a><span class="fu">entry:</span></span>
-<span id="cb96-3"><a href="#cb96-3" aria-hidden="true" tabindex="-1"></a>  <span class="co">; Try the .true branch</span></span>
-<span id="cb96-4"><a href="#cb96-4" aria-hidden="true" tabindex="-1"></a>  <span class="fu">%r1</span> = <span class="kw">call</span> <span class="fu">%KOpt</span> <span class="fu">@project_true</span>(<span class="fu">%in</span>)</span>
-<span id="cb96-5"><a href="#cb96-5" aria-hidden="true" tabindex="-1"></a>  <span class="fu">%ok1</span> = <span class="kw">extractvalue</span> <span class="fu">%KOpt</span> <span class="fu">%r1</span>, <span class="dv">0</span></span>
-<span id="cb96-6"><a href="#cb96-6" aria-hidden="true" tabindex="-1"></a>  <span class="kw">br</span> <span class="dt">i1</span> <span class="fu">%ok1</span>, <span class="dt">label</span> <span class="fu">%case_true</span>, <span class="dt">label</span> <span class="fu">%case_false</span></span>
-<span id="cb96-7"><a href="#cb96-7" aria-hidden="true" tabindex="-1"></a></span>
-<span id="cb96-8"><a href="#cb96-8" aria-hidden="true" tabindex="-1"></a><span class="fu">case_true:</span></span>
-<span id="cb96-9"><a href="#cb96-9" aria-hidden="true" tabindex="-1"></a>  <span class="fu">%res_true</span> = <span class="kw">insertvalue</span> <span class="fu">%KOpt</span> <span class="kw">undef</span>, <span class="dt">i1</span> <span class="dv">1</span>, <span class="dv">0</span></span>
-<span id="cb96-10"><a href="#cb96-10" aria-hidden="true" tabindex="-1"></a>  <span class="fu">%res_true2</span> = <span class="kw">insertvalue</span> <span class="fu">%KOpt</span> <span class="fu">%res_true</span>, <span class="fu">%KVal</span> <span class="fu">@false_node</span>, <span class="dv">1</span></span>
-<span id="cb96-11"><a href="#cb96-11" aria-hidden="true" tabindex="-1"></a>  <span class="kw">ret</span> <span class="fu">%KOpt</span> <span class="fu">%res_true2</span></span>
-<span id="cb96-12"><a href="#cb96-12" aria-hidden="true" tabindex="-1"></a></span>
-<span id="cb96-13"><a href="#cb96-13" aria-hidden="true" tabindex="-1"></a><span class="fu">case_false:</span></span>
-<span id="cb96-14"><a href="#cb96-14" aria-hidden="true" tabindex="-1"></a>  <span class="fu">%r2</span> = <span class="kw">call</span> <span class="fu">%KOpt</span> <span class="fu">@project_false</span>(<span class="fu">%in</span>)</span>
-<span id="cb96-15"><a href="#cb96-15" aria-hidden="true" tabindex="-1"></a>  <span class="fu">%ok2</span> = <span class="kw">extractvalue</span> <span class="fu">%KOpt</span> <span class="fu">%r2</span>, <span class="dv">0</span></span>
-<span id="cb96-16"><a href="#cb96-16" aria-hidden="true" tabindex="-1"></a>  <span class="kw">br</span> <span class="dt">i1</span> <span class="fu">%ok2</span>, <span class="dt">label</span> <span class="fu">%case_false_valid</span>, <span class="dt">label</span> <span class="fu">%undefined</span></span>
-<span id="cb96-17"><a href="#cb96-17" aria-hidden="true" tabindex="-1"></a></span>
-<span id="cb96-18"><a href="#cb96-18" aria-hidden="true" tabindex="-1"></a><span class="fu">case_false_valid:</span></span>
-<span id="cb96-19"><a href="#cb96-19" aria-hidden="true" tabindex="-1"></a>  <span class="fu">%res_false</span> = <span class="kw">insertvalue</span> <span class="fu">%KOpt</span> <span class="kw">undef</span>, <span class="dt">i1</span> <span class="dv">1</span>, <span class="dv">0</span></span>
-<span id="cb96-20"><a href="#cb96-20" aria-hidden="true" tabindex="-1"></a>  <span class="fu">%res_false2</span> = <span class="kw">insertvalue</span> <span class="fu">%KOpt</span> <span class="fu">%res_false</span>, <span class="fu">%KVal</span> <span class="fu">@true_node</span>, <span class="dv">1</span></span>
-<span id="cb96-21"><a href="#cb96-21" aria-hidden="true" tabindex="-1"></a>  <span class="kw">ret</span> <span class="fu">%KOpt</span> <span class="fu">%res_false2</span></span>
-<span id="cb96-22"><a href="#cb96-22" aria-hidden="true" tabindex="-1"></a></span>
-<span id="cb96-23"><a href="#cb96-23" aria-hidden="true" tabindex="-1"></a><span class="fu">undefined:</span></span>
-<span id="cb96-24"><a href="#cb96-24" aria-hidden="true" tabindex="-1"></a>  <span class="kw">ret</span> <span class="fu">%KOpt</span> { <span class="dt">i1</span> <span class="dv">0</span>, <span class="fu">%KVal</span> <span class="kw">undef</span> }</span>
-<span id="cb96-25"><a href="#cb96-25" aria-hidden="true" tabindex="-1"></a>}</span></code></pre></div>
-<p>While verbose, this code mirrors the evaluation rules exactly and can
-be optimized by standard LLVM tools.</p>
-<hr />
-<h2 id="optimization-and-verification"><strong>11.10 Optimization and
-verification</strong></h2>
-<p>LLVM provides built-in passes that simplify generated code:</p>
-<ul>
-<li><strong>mem2reg</strong> — removes unnecessary memory
-operations,</li>
-<li><strong>instcombine</strong> — merges simple operations,</li>
-<li><strong>gvn</strong> — removes redundant calculations,</li>
-<li><strong>simplifycfg</strong> — cleans up control flow.</li>
-</ul>
-<p>The compiler can run these passes automatically to produce compact
-and efficient output. LLVM also verifies that all types and values are
-consistent before emitting machine code.</p>
-<hr />
-<h2 id="summary-9"><strong>11.11 Summary</strong></h2>
-<ul>
-<li>LLVM IR is a portable, low-level language ideal for code
-generation.</li>
-<li>Every <code>k</code> function becomes an LLVM function returning the
-pair <code>{ok, value}</code>.</li>
-<li>All constants, type checks, and runtime calls are represented
-explicitly.</li>
-<li>The translation from <code>k</code>’s intermediate form to LLVM is
-direct and systematic.</li>
-<li>Standard LLVM tools can then optimize and compile the result into
-executable machine code.</li>
-</ul>
-<hr />
-<hr />
-<h1 id="chapter-12-code-generation">Chapter 12 — Code Generation</h1>
-<h2 id="purpose-3"><strong>12.1 Purpose</strong></h2>
-<p>The <strong>code generation</strong> phase translates the
-intermediate representation (IR) of each k function into executable code
-using the LLVM format described in Chapter 11. This translation is
-systematic: every IR operation corresponds to a specific sequence of
-LLVM instructions or calls to the runtime library.</p>
-<p>The compiler’s objective is to produce code that behaves exactly like
-the formal semantics of k—no more and no less. Each step of the
-translation can therefore be viewed as a mechanical implementation of
-one of the rules introduced in Chapter 8.</p>
-<hr />
-<h2 id="structure-of-generated-functions"><strong>12.2 Structure of
-generated functions</strong></h2>
-<p>Each k function becomes a stand-alone LLVM function with the
-signature:</p>
-<div class="sourceCode" id="cb97"><pre
-class="sourceCode llvm"><code class="sourceCode llvm"><span id="cb97-1"><a href="#cb97-1" aria-hidden="true" tabindex="-1"></a><span class="kw">define</span> <span class="fu">%KOpt</span> <span class="fu">@f_name</span>(<span class="fu">%KVal</span> <span class="fu">%in</span>)</span></code></pre></div>
-<p>Internally, the function has one or more <em>basic blocks</em>. Each
-block performs a small action: a projection, a check, a call, or a node
-construction. Blocks are connected by explicit branches that depend on
-the <code>ok</code> flag of intermediate results.</p>
-<p>At the end of the function, exactly one <code>%KOpt</code> value is
-returned.</p>
-<hr />
-<h2 id="translating-core-operations"><strong>12.3 Translating core
-operations</strong></h2>
-<p>The compiler maintains a mapping from IR operations (Chapter 10) to
-LLVM code patterns.</p>
-<table>
-<colgroup>
-<col style="width: 21%" />
-<col style="width: 78%" />
-</colgroup>
-<thead>
-<tr>
-<th>IR Operation</th>
-<th>Generated Code Pattern</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td><strong>PROJECT label</strong></td>
-<td><code>call %KOpt @k_project(%KVal %in, i32 label_id)</code></td>
-</tr>
-<tr>
-<td><strong>TYPECHECK state</strong></td>
-<td>Compare <code>input-&gt;state</code> with constant
-<code>state</code>; if unequal, return <code>{0, undef}</code></td>
-</tr>
-<tr>
-<td><strong>CONST node</strong></td>
-<td>Return <code>{1, node_pointer}</code></td>
-</tr>
-<tr>
-<td><strong>SEQ [f₁,f₂,…]</strong></td>
-<td>Emit each function call in order, test <code>ok</code> after
-each</td>
-</tr>
-<tr>
-<td><strong>UNION [f₁,f₂,…]</strong></td>
-<td>Emit chained <code>if</code> blocks; return first successful
-result</td>
-</tr>
-<tr>
-<td><strong>PRODUCT [l₁=f₁, …]</strong></td>
-<td>Call all subfunctions; if all succeed, collect children and call
-<code>@k_make_product</code></td>
-</tr>
-<tr>
-<td><strong>FAIL</strong></td>
-<td>Return <code>{0, undef}</code> immediately</td>
-</tr>
-</tbody>
-</table>
-<p>These templates cover the entire language.</p>
-<hr />
-<h2 id="example-sequential-composition"><strong>12.4 Example: sequential
-composition</strong></h2>
-<p>For IR:</p>
-<pre><code>SEQ [ PROJECT x, CALL f, CALL g ]</code></pre>
-<p>the compiler emits:</p>
-<div class="sourceCode" id="cb99"><pre
-class="sourceCode llvm"><code class="sourceCode llvm"><span id="cb99-1"><a href="#cb99-1" aria-hidden="true" tabindex="-1"></a><span class="fu">%r1</span> = <span class="kw">call</span> <span class="fu">%KOpt</span> <span class="fu">@k_project_x</span>(<span class="fu">%in</span>)</span>
-<span id="cb99-2"><a href="#cb99-2" aria-hidden="true" tabindex="-1"></a><span class="fu">%ok1</span> = <span class="kw">extractvalue</span> <span class="fu">%KOpt</span> <span class="fu">%r1</span>, <span class="dv">0</span></span>
-<span id="cb99-3"><a href="#cb99-3" aria-hidden="true" tabindex="-1"></a><span class="kw">br</span> <span class="dt">i1</span> <span class="fu">%ok1</span>, <span class="dt">label</span> <span class="fu">%cont1</span>, <span class="dt">label</span> <span class="fu">%fail</span></span>
-<span id="cb99-4"><a href="#cb99-4" aria-hidden="true" tabindex="-1"></a></span>
-<span id="cb99-5"><a href="#cb99-5" aria-hidden="true" tabindex="-1"></a><span class="fu">cont1:</span></span>
-<span id="cb99-6"><a href="#cb99-6" aria-hidden="true" tabindex="-1"></a><span class="fu">%r2</span> = <span class="kw">call</span> <span class="fu">%KOpt</span> <span class="fu">@f</span>(<span class="fu">%r1.val</span>)</span>
-<span id="cb99-7"><a href="#cb99-7" aria-hidden="true" tabindex="-1"></a><span class="fu">%ok2</span> = <span class="kw">extractvalue</span> <span class="fu">%KOpt</span> <span class="fu">%r2</span>, <span class="dv">0</span></span>
-<span id="cb99-8"><a href="#cb99-8" aria-hidden="true" tabindex="-1"></a><span class="kw">br</span> <span class="dt">i1</span> <span class="fu">%ok2</span>, <span class="dt">label</span> <span class="fu">%cont2</span>, <span class="dt">label</span> <span class="fu">%fail</span></span>
-<span id="cb99-9"><a href="#cb99-9" aria-hidden="true" tabindex="-1"></a></span>
-<span id="cb99-10"><a href="#cb99-10" aria-hidden="true" tabindex="-1"></a><span class="fu">cont2:</span></span>
-<span id="cb99-11"><a href="#cb99-11" aria-hidden="true" tabindex="-1"></a><span class="fu">%r3</span> = <span class="kw">call</span> <span class="fu">%KOpt</span> <span class="fu">@g</span>(<span class="fu">%r2.val</span>)</span>
-<span id="cb99-12"><a href="#cb99-12" aria-hidden="true" tabindex="-1"></a><span class="kw">ret</span> <span class="fu">%KOpt</span> <span class="fu">%r3</span></span>
-<span id="cb99-13"><a href="#cb99-13" aria-hidden="true" tabindex="-1"></a></span>
-<span id="cb99-14"><a href="#cb99-14" aria-hidden="true" tabindex="-1"></a><span class="fu">fail:</span></span>
-<span id="cb99-15"><a href="#cb99-15" aria-hidden="true" tabindex="-1"></a><span class="kw">ret</span> <span class="fu">%KOpt</span> { <span class="dt">i1</span> <span class="dv">0</span>, <span class="fu">%KVal</span> <span class="kw">undef</span> }</span></code></pre></div>
-<p>Each block corresponds to one stage in the composition. The use of
-conditional branches ensures that undefinedness propagates
-correctly.</p>
-<hr />
-<h2 id="example-product-composition-1"><strong>12.5 Example: product
-composition</strong></h2>
-<p>For IR:</p>
-<pre><code>PRODUCT [ a = PROJECT x, b = PROJECT y ]</code></pre>
-<p>the compiler generates code equivalent to:</p>
-<div class="sourceCode" id="cb101"><pre
-class="sourceCode llvm"><code class="sourceCode llvm"><span id="cb101-1"><a href="#cb101-1" aria-hidden="true" tabindex="-1"></a><span class="fu">%ra</span> = <span class="kw">call</span> <span class="fu">%KOpt</span> <span class="fu">@k_project_x</span>(<span class="fu">%in</span>)</span>
-<span id="cb101-2"><a href="#cb101-2" aria-hidden="true" tabindex="-1"></a><span class="fu">%ok_a</span> = <span class="kw">extractvalue</span> <span class="fu">%KOpt</span> <span class="fu">%ra</span>, <span class="dv">0</span></span>
-<span id="cb101-3"><a href="#cb101-3" aria-hidden="true" tabindex="-1"></a><span class="kw">br</span> <span class="dt">i1</span> <span class="fu">%ok_a</span>, <span class="dt">label</span> <span class="fu">%try_b</span>, <span class="dt">label</span> <span class="fu">%fail</span></span>
-<span id="cb101-4"><a href="#cb101-4" aria-hidden="true" tabindex="-1"></a></span>
-<span id="cb101-5"><a href="#cb101-5" aria-hidden="true" tabindex="-1"></a><span class="fu">try_b:</span></span>
-<span id="cb101-6"><a href="#cb101-6" aria-hidden="true" tabindex="-1"></a><span class="fu">%rb</span> = <span class="kw">call</span> <span class="fu">%KOpt</span> <span class="fu">@k_project_y</span>(<span class="fu">%in</span>)</span>
-<span id="cb101-7"><a href="#cb101-7" aria-hidden="true" tabindex="-1"></a><span class="fu">%ok_b</span> = <span class="kw">extractvalue</span> <span class="fu">%KOpt</span> <span class="fu">%rb</span>, <span class="dv">0</span></span>
-<span id="cb101-8"><a href="#cb101-8" aria-hidden="true" tabindex="-1"></a><span class="fu">%ok_all</span> = <span class="kw">and</span> <span class="dt">i1</span> <span class="fu">%ok_a</span>, <span class="fu">%ok_b</span></span>
-<span id="cb101-9"><a href="#cb101-9" aria-hidden="true" tabindex="-1"></a><span class="kw">br</span> <span class="dt">i1</span> <span class="fu">%ok_all</span>, <span class="dt">label</span> <span class="fu">%build</span>, <span class="dt">label</span> <span class="fu">%fail</span></span>
-<span id="cb101-10"><a href="#cb101-10" aria-hidden="true" tabindex="-1"></a></span>
-<span id="cb101-11"><a href="#cb101-11" aria-hidden="true" tabindex="-1"></a><span class="fu">build:</span></span>
-<span id="cb101-12"><a href="#cb101-12" aria-hidden="true" tabindex="-1"></a><span class="fu">%children</span> = <span class="kw">alloca</span> [<span class="fu">%KVal</span>, <span class="dv">2</span>]</span>
-<span id="cb101-13"><a href="#cb101-13" aria-hidden="true" tabindex="-1"></a><span class="fu">%p0</span> = <span class="kw">getelementptr</span> [<span class="fu">%KVal</span>,<span class="dv">2</span>], [<span class="fu">%KVal</span>,<span class="dv">2</span>]* <span class="fu">%children</span>, <span class="dt">i32</span> <span class="dv">0</span>, <span class="dt">i32</span> <span class="dv">0</span></span>
-<span id="cb101-14"><a href="#cb101-14" aria-hidden="true" tabindex="-1"></a><span class="kw">store</span> <span class="fu">%KVal</span> (<span class="kw">extractvalue</span> <span class="fu">%KOpt</span> <span class="fu">%ra</span>, <span class="dv">1</span>), <span class="fu">%KVal</span>* <span class="fu">%p0</span></span>
-<span id="cb101-15"><a href="#cb101-15" aria-hidden="true" tabindex="-1"></a><span class="fu">%p1</span> = <span class="kw">getelementptr</span> [<span class="fu">%KVal</span>,<span class="dv">2</span>], [<span class="fu">%KVal</span>,<span class="dv">2</span>]* <span class="fu">%children</span>, <span class="dt">i32</span> <span class="dv">0</span>, <span class="dt">i32</span> <span class="dv">1</span></span>
-<span id="cb101-16"><a href="#cb101-16" aria-hidden="true" tabindex="-1"></a><span class="kw">store</span> <span class="fu">%KVal</span> (<span class="kw">extractvalue</span> <span class="fu">%KOpt</span> <span class="fu">%rb</span>, <span class="dv">1</span>), <span class="fu">%KVal</span>* <span class="fu">%p1</span></span>
-<span id="cb101-17"><a href="#cb101-17" aria-hidden="true" tabindex="-1"></a><span class="fu">%res</span> = <span class="kw">call</span> <span class="fu">%KVal</span> <span class="fu">@k_make_product</span>(<span class="dt">i32</span> state_id, <span class="dt">i32</span> <span class="dv">2</span>, <span class="fu">%KVal</span>* <span class="fu">%children</span>)</span>
-<span id="cb101-18"><a href="#cb101-18" aria-hidden="true" tabindex="-1"></a><span class="kw">ret</span> <span class="fu">%KOpt</span> { <span class="dt">i1</span> <span class="dv">1</span>, <span class="fu">%KVal</span> <span class="fu">%res</span> }</span>
-<span id="cb101-19"><a href="#cb101-19" aria-hidden="true" tabindex="-1"></a></span>
-<span id="cb101-20"><a href="#cb101-20" aria-hidden="true" tabindex="-1"></a><span class="fu">fail:</span></span>
-<span id="cb101-21"><a href="#cb101-21" aria-hidden="true" tabindex="-1"></a><span class="kw">ret</span> <span class="fu">%KOpt</span> { <span class="dt">i1</span> <span class="dv">0</span>, <span class="fu">%KVal</span> <span class="kw">undef</span> }</span></code></pre></div>
-<p>The resulting LLVM code faithfully follows the semantic rule: the
-product is defined only if all components are defined.</p>
-<hr />
-<h2 id="example-union-composition"><strong>12.6 Example: union
-composition</strong></h2>
-<p>For IR:</p>
-<pre><code>UNION [ .x, .y ]</code></pre>
-<p>the compiler produces a branching structure:</p>
-<div class="sourceCode" id="cb103"><pre
-class="sourceCode llvm"><code class="sourceCode llvm"><span id="cb103-1"><a href="#cb103-1" aria-hidden="true" tabindex="-1"></a><span class="fu">%r1</span> = <span class="kw">call</span> <span class="fu">%KOpt</span> <span class="fu">@k_project_x</span>(<span class="fu">%in</span>)</span>
-<span id="cb103-2"><a href="#cb103-2" aria-hidden="true" tabindex="-1"></a><span class="fu">%ok1</span> = <span class="kw">extractvalue</span> <span class="fu">%KOpt</span> <span class="fu">%r1</span>, <span class="dv">0</span></span>
-<span id="cb103-3"><a href="#cb103-3" aria-hidden="true" tabindex="-1"></a><span class="kw">br</span> <span class="dt">i1</span> <span class="fu">%ok1</span>, <span class="dt">label</span> <span class="fu">%merge</span>, <span class="dt">label</span> <span class="fu">%try_next</span></span>
-<span id="cb103-4"><a href="#cb103-4" aria-hidden="true" tabindex="-1"></a></span>
-<span id="cb103-5"><a href="#cb103-5" aria-hidden="true" tabindex="-1"></a><span class="fu">try_next:</span></span>
-<span id="cb103-6"><a href="#cb103-6" aria-hidden="true" tabindex="-1"></a><span class="fu">%r2</span> = <span class="kw">call</span> <span class="fu">%KOpt</span> <span class="fu">@k_project_y</span>(<span class="fu">%in</span>)</span>
-<span id="cb103-7"><a href="#cb103-7" aria-hidden="true" tabindex="-1"></a><span class="kw">br</span> <span class="dt">label</span> <span class="fu">%merge</span></span>
-<span id="cb103-8"><a href="#cb103-8" aria-hidden="true" tabindex="-1"></a></span>
-<span id="cb103-9"><a href="#cb103-9" aria-hidden="true" tabindex="-1"></a><span class="fu">merge:</span></span>
-<span id="cb103-10"><a href="#cb103-10" aria-hidden="true" tabindex="-1"></a><span class="fu">%res</span> = <span class="kw">phi</span> <span class="fu">%KOpt</span> [ <span class="fu">%r1</span>, <span class="fu">%ok1</span> ], [ <span class="fu">%r2</span>, <span class="fu">%try_next</span> ]</span>
-<span id="cb103-11"><a href="#cb103-11" aria-hidden="true" tabindex="-1"></a><span class="kw">ret</span> <span class="fu">%KOpt</span> <span class="fu">%res</span></span></code></pre></div>
-<p>This pattern ensures that the first defined branch wins, as specified
-by the semantics.</p>
-<hr />
-<h2 id="managing-constants-and-types"><strong>12.7 Managing constants
-and types</strong></h2>
-<p>Whenever an expression references a constant value or a type
-restriction:</p>
-<ul>
-<li><strong>Constant values</strong> are replaced by pointers to global
-constant nodes.</li>
-<li><strong>Type expressions <code>$T</code></strong> are compiled to a
-<code>TYPECHECK</code> instruction: if
-<code>input-&gt;state != T_state</code>, the function returns
-undefined.</li>
-</ul>
-<p>This approach removes all high-level notation before reaching machine
-level.</p>
-<hr />
-<h2 id="optimizing-during-generation"><strong>12.8 Optimizing during
-generation</strong></h2>
-<p>Because the structure of k is very regular, many optimizations can be
-applied while generating code:</p>
-<ul>
-<li><strong>Eliminate redundant checks</strong> — consecutive type
-checks on the same state can be merged.</li>
-<li><strong>Inline small functions</strong> — short constant or
-projection functions can be inserted directly into their callers.</li>
-<li><strong>Remove unreachable branches</strong> — if a type restriction
-guarantees that one union branch can never apply, it is omitted.</li>
-</ul>
-<p>Such simplifications can be done by the compiler itself or delegated
-to LLVM’s optimization passes.</p>
-<hr />
-<h2 id="interaction-with-the-runtime"><strong>12.9 Interaction with the
-runtime</strong></h2>
-<p>All allocation and field access are performed through runtime calls.
-The compiler never manipulates pointers directly beyond passing them to
-these helpers. This design ensures that compiled code is independent of
-the internal memory layout.</p>
-<p>The generated functions thus resemble small graphs of calls and
-conditionals built entirely on top of the fixed ABI.</p>
-<hr />
-<h2 id="linking-and-verification"><strong>12.10 Linking and
-verification</strong></h2>
-<p>After all functions are emitted, the compiler writes a single LLVM
-module containing:</p>
-<ul>
-<li>all generated functions,</li>
-<li>declarations of runtime primitives (<code>k_project</code>,
-<code>k_make_product</code>, etc.),</li>
-<li>and constant nodes representing literal values.</li>
-</ul>
-<p>The LLVM verifier then checks that:</p>
-<ul>
-<li>every function returns a correctly typed <code>%KOpt</code>,</li>
-<li>all control-flow paths end with a <code>ret</code>,</li>
-<li>and all global references are defined.</li>
-</ul>
-<p>Only verified code is passed to the optimizer or the machine-code
-generator.</p>
-<hr />
-<h2 id="summary-10"><strong>12.11 Summary</strong></h2>
-<ul>
-<li>Code generation turns IR into real executable instructions.</li>
-<li>Each k function maps to an LLVM function returning
-<code>{ok, value}</code>.</li>
-<li>Projection, composition, union, and product translate into small,
-fixed code patterns.</li>
-<li>Type restrictions become simple integer comparisons.</li>
-<li>The compiler can apply immediate simplifications during
-translation.</li>
-<li>The final output is a verified LLVM module ready for optimization
-and linking.</li>
-</ul>
-<h1 id="chapter-13-linking-and-execution">Chapter 13 — Linking and
-Execution</h1>
-<h2 id="purpose-4"><strong>13.1 Purpose</strong></h2>
-<p>The last stage of compilation connects the generated code with the
-runtime library and produces an executable program. This process is
-called <strong>linking</strong>. Once linked, the program can be run
-like any other compiled program: it reads input values, executes the
-compiled k functions, and returns a result.</p>
-<p>The linking and execution stages ensure that the compiled code, the
-runtime library, and the data it manipulates all agree on structure and
-conventions.</p>
-<hr />
-<h2 id="the-runtime-library"><strong>13.2 The runtime
-library</strong></h2>
-<p>All compiled k programs depend on a small runtime component, often
-distributed as a file named <code>krt.c</code> or <code>krt.o</code>.
-This library provides:</p>
-<table>
-<colgroup>
-<col style="width: 41%" />
-<col style="width: 58%" />
-</colgroup>
-<thead>
-<tr>
-<th>Function</th>
-<th>Purpose</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td><code>k_make_product(state, n, children)</code></td>
-<td>Allocate a product node with <code>n</code> fields.</td>
-</tr>
-<tr>
-<td><code>k_make_union(state, tag, child)</code></td>
-<td>Allocate a union node with a single variant.</td>
-</tr>
-<tr>
-<td><code>k_project(input, label_id)</code></td>
-<td>Perform projection <code>.label</code>.</td>
-</tr>
-<tr>
-<td><code>k_fail()</code></td>
-<td>Return a predefined undefined result <code>{ ok = 0 }</code>.</td>
-</tr>
-<tr>
-<td><code>k_unit()</code></td>
-<td>Return the constant unit value <code>{}</code>.</td>
-</tr>
-</tbody>
-</table>
-<p>These functions implement the same concepts as the semantic rules
-described earlier, but at the level of actual memory operations. They
-are compiled once in a low-level language such as C and reused by all
-generated programs.</p>
-<hr />
-<h2 id="metadata-tables-1"><strong>13.3 Metadata tables</strong></h2>
-<p>Along with the runtime functions, the compiler produces
-<strong>metadata</strong> describing each canonical type used in the
-program:</p>
-<ul>
-<li><code>state_kind[state]</code> — <code>0</code> for product,
-<code>1</code> for union</li>
-<li><code>state_arity[state]</code> — number of children</li>
-<li><code>field_index[state][label_id]</code> — position of field
-<code>label_id</code> within product</li>
-<li><code>variant_index[state][label_id]</code> — tag number for variant
-<code>label_id</code> within union</li>
-</ul>
-<p>These tables are stored as constant arrays in the compiled module.
-Runtime functions use them to interpret and construct nodes correctly
-without needing any dynamic reflection.</p>
-<hr />
-<h2 id="linking"><strong>13.4 Linking</strong></h2>
-<p>The generated LLVM file is compiled and linked with the runtime
-library in two simple steps:</p>
-<div class="sourceCode" id="cb104"><pre
-class="sourceCode bash"><code class="sourceCode bash"><span id="cb104-1"><a href="#cb104-1" aria-hidden="true" tabindex="-1"></a><span class="fu">clang</span> <span class="at">-O2</span> <span class="at">-c</span> krt.c <span class="at">-o</span> krt.o</span>
-<span id="cb104-2"><a href="#cb104-2" aria-hidden="true" tabindex="-1"></a><span class="fu">clang</span> <span class="at">-O2</span> program.ll krt.o <span class="at">-o</span> program</span></code></pre></div>
-<p>The first command compiles the runtime once. The second command
-combines the runtime with the program’s own functions and constant
-definitions.</p>
-<p>The result is a native executable file named <code>program</code>.
-When run, it behaves exactly like the original k program.</p>
-<hr />
-<h2 id="initialization"><strong>13.5 Initialization</strong></h2>
-<p>When the executable starts, it performs a few basic steps:</p>
-<ol type="1">
-<li>Allocate an <strong>arena</strong> for storing newly created
-nodes.</li>
-<li>Initialize constant nodes such as the unit <code>{}</code> and any
-user-defined constants.</li>
-<li>Optionally, prepare a table of function pointers for fast
-invocation.</li>
-</ol>
-<p>After initialization, the main compiled function can be called
-directly.</p>
-<hr />
-<h2 id="executing-a-compiled-function"><strong>13.6 Executing a compiled
-function</strong></h2>
-<p>Every compiled function has the signature:</p>
-<div class="sourceCode" id="cb105"><pre
-class="sourceCode c"><code class="sourceCode c"><span id="cb105-1"><a href="#cb105-1" aria-hidden="true" tabindex="-1"></a><span class="kw">struct</span> KOpt function<span class="op">(</span><span class="kw">struct</span> KNode<span class="op">*</span> input<span class="op">);</span></span></code></pre></div>
-<p>To run a program, a caller must supply an input value tree in the
-expected canonical form. The value is typically created by another
-function or loaded from serialized data.</p>
-<p>For example, to execute a function <code>neg</code> expecting a
-<code>$bool</code>:</p>
-<div class="sourceCode" id="cb106"><pre
-class="sourceCode c"><code class="sourceCode c"><span id="cb106-1"><a href="#cb106-1" aria-hidden="true" tabindex="-1"></a><span class="kw">struct</span> KOpt result <span class="op">=</span> neg<span class="op">(&amp;</span>true_node<span class="op">);</span></span>
-<span id="cb106-2"><a href="#cb106-2" aria-hidden="true" tabindex="-1"></a><span class="cf">if</span> <span class="op">(</span>result<span class="op">.</span>ok<span class="op">)</span></span>
-<span id="cb106-3"><a href="#cb106-3" aria-hidden="true" tabindex="-1"></a>    print_value<span class="op">(</span>result<span class="op">.</span>val<span class="op">);</span></span>
-<span id="cb106-4"><a href="#cb106-4" aria-hidden="true" tabindex="-1"></a><span class="cf">else</span></span>
-<span id="cb106-5"><a href="#cb106-5" aria-hidden="true" tabindex="-1"></a>    printf<span class="op">(</span><span class="st">&quot;undefined</span><span class="sc">\n</span><span class="st">&quot;</span><span class="op">);</span></span></code></pre></div>
-<p>If the input is <code>{ {} true }</code>, the output will be
-<code>{ {} false }</code>.</p>
-<hr />
-<h2 id="input-and-output-conventions"><strong>13.7 Input and output
-conventions</strong></h2>
-<p>At the machine level, a “value” is always represented by a pointer to
-a <code>KNode</code>. Each compiled function expects exactly one such
-pointer. When a function returns, its output pointer may refer to an
-existing constant node, a new node allocated in the arena, or nothing at
-all if undefined.</p>
-<p>There is no special I/O system in k itself; printing or reading
-values is the responsibility of the host environment. In practice,
-programs are tested by calling compiled functions from C or Python and
-inspecting their returned structures.</p>
-<hr />
-<h2 id="debugging-and-inspection"><strong>13.8 Debugging and
-inspection</strong></h2>
-<p>Because both the generated code and the runtime library are
-deterministic and memory-safe, debugging usually consists of examining
-node contents.</p>
-<p>Two simple runtime utilities are useful:</p>
-<ul>
-<li><code>print_value(node)</code> — prints a tree in human-readable
-form.</li>
-<li><code>print_type(state)</code> — prints the canonical description of
-a type state.</li>
-</ul>
-<p>They allow the user to confirm that compiled functions construct the
-correct tree shapes.</p>
-<hr />
-<h2 id="verification"><strong>13.9 Verification</strong></h2>
-<p>After linking, the compiler can run a <em>self-verification
-pass</em>:</p>
-<ol type="1">
-<li>Construct small sample inputs for each exported function.</li>
-<li>Execute the compiled function.</li>
-<li>Compare results with the interpreter’s result using structural
-equality.</li>
-</ol>
-<p>If all match, the compiler’s translation is confirmed correct for
-those test cases. This method is especially valuable during compiler
-development and textbook exercises.</p>
-<hr />
-<h2 id="example-complete-run"><strong>13.10 Example: complete
-run</strong></h2>
-<p>Example program:</p>
-<pre><code>$bool = &lt; {} true, {} false &gt;;
-neg = $bool &lt; .true {{ } false}, .false {{ } true} &gt; $bool;</code></pre>
-<p>Steps:</p>
-<ol type="1">
-<li>Compile to <code>neg.ll</code>.</li>
-<li>Link with <code>krt.o</code>.</li>
-<li>Run a small C driver that calls <code>neg</code>.</li>
-</ol>
-<p>Output:</p>
-<pre><code>input  = {{ } true}
-result = {{ } false}</code></pre>
-<p>If <code>input</code> is <code>{}</code> or any
-non-<code>$bool</code> value, the function is undefined and prints
-“undefined”.</p>
-<hr />
-<h2 id="summary-11"><strong>13.11 Summary</strong></h2>
-<ul>
-<li>Linking combines generated LLVM code with the shared runtime
-library.</li>
-<li>The runtime provides allocation, projection, and constant
-handling.</li>
-<li>Metadata tables describe type structure to the runtime.</li>
-<li>Every compiled function follows the uniform calling convention
-<code>KOpt f(KNode*)</code>.</li>
-<li>Execution produces immutable tree values exactly matching the
-semantics of k.</li>
-<li>Verification against the interpreter ensures correctness of the
-translation.</li>
-</ul>
-<h1 id="chapter-14-canonical-serialization">Chapter 14 — Canonical
-Serialization</h1>
-<h2 id="purpose-5"><strong>14.1 Purpose</strong></h2>
-<p>Serialization is the process of converting a value in memory into a
-compact sequence of bits or bytes that can be stored or transmitted. For
-the k language, serialization serves an additional goal: it defines a
-<strong>canonical representation</strong> of each value that is unique
-and independent of the machine on which it was produced.</p>
-<p>A canonical encoding allows values to be compared, hashed, or stored
-in a registry in a reproducible way. Two values that are structurally
-identical will always produce the same bit sequence.</p>
-<hr />
-<h2 id="canonical-type-information"><strong>14.2 Canonical type
-information</strong></h2>
-<p>Serialization always depends on the <strong>canonical form of the
-type</strong>. A type in canonical form is a finite tree automaton
-(Chapter 3) that describes the structure of all its values. Because this
-form is unique, every possible value of the type can be encoded
-deterministically.</p>
-<p>Before any value is serialized, the compiler or runtime must
-know:</p>
-<ul>
-<li>the list of states (C0, C1, …),</li>
-<li>for each state, whether it is a product or a union,</li>
-<li>the number of possible transitions, and</li>
-<li>for unions, the order of their variants.</li>
-</ul>
-<p>This information acts as the grammar from which all bit sequences are
-derived.</p>
-<hr />
-<h2 id="encoding-principle"><strong>14.3 Encoding
-principle</strong></h2>
-<p>Each node in a value tree corresponds to one of the type’s
-states.</p>
-<ul>
-<li><strong>Product node</strong> – emits no bits; the encoder simply
-serializes each child in canonical field order.</li>
-<li><strong>Union node</strong> – emits a small binary code that
-identifies which variant is used, then serializes its single child.</li>
-<li><strong>Unit node</strong> (empty product) – emits nothing; it has
-no children.</li>
-<li><strong>Empty union</strong> – cannot be encoded because it has no
-possible values.</li>
-</ul>
-<p>Thus, the sequence of bits records exactly which union branches were
-taken while descending the tree.</p>
-<hr />
-<h2 id="fixed-length-codes-per-state"><strong>14.4 Fixed-length codes
-per state</strong></h2>
-<p>For simplicity, each union state uses fixed-length binary codes of
-equal size.</p>
-<p>If a union has <em>m</em> variants, then</p>
-<pre><code>k = ceil(log2(m))</code></pre>
-<p>bits are needed. Each variant is numbered in canonical order from 0
-to m − 1 and represented by the binary form of its index.</p>
-<p>Products and units use k = 0 and emit no bits.</p>
-<p>This rule allows the decoder to know, from the type alone, how many
-bits to read at each step.</p>
-<hr />
-<h2 id="example-natural-numbers-1"><strong>14.5 Example: natural
-numbers</strong></h2>
-<p>For the type</p>
-<pre><code>$bnat = &lt; bnat 0, bnat 1, {} _ &gt;;</code></pre>
-<p>the canonical form has three transitions from state C0. Therefore,
-<code>k = ceil(log2(3)) = 2</code> bits are required per union node.</p>
-<p>Assigning codes in order:</p>
-<table>
-<thead>
-<tr>
-<th>Rule</th>
-<th>Code</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td>C0 → {C0 “0”}</td>
-<td><code>00</code></td>
-</tr>
-<tr>
-<td>C0 → {C0 “1”}</td>
-<td><code>01</code></td>
-</tr>
-<tr>
-<td>C0 → {C1 “_” }</td>
-<td><code>10</code></td>
-</tr>
-</tbody>
-</table>
-<p>The value <code>{ {{ {} _ } 1 } 0 }</code> is encoded by
-concatenating the codes of the transitions chosen during a leftmost
-derivation:</p>
-<pre><code>00 → first C0
-01 → next C0
-10 → final C0</code></pre>
-<p>Resulting bit sequence: <code>000110</code>.</p>
-<hr />
-<h2 id="decoding"><strong>14.6 Decoding</strong></h2>
-<p>Decoding is deterministic and mirrors the encoding process:</p>
-<ol type="1">
-<li>Start at the root state (C0).</li>
-<li>If the current state is a union, read k bits to choose a rule.</li>
-<li>Create the corresponding node, then recursively decode its child or
-children.</li>
-<li>For products, decode all children in order; for units, stop.</li>
-</ol>
-<p>The decoder stops when the entire tree has been reconstructed and all
-bits have been consumed.</p>
-<p>Because every union code is of fixed length, the decoding process
-requires no backtracking and can be implemented as a simple loop.</p>
-<hr />
-<h2 id="folding-repeated-subtrees"><strong>14.7 Folding repeated
-subtrees</strong></h2>
-<p>Many values contain repeated substructures. To avoid serializing the
-same tree several times, identical subtrees can be <em>folded</em> into
-a <strong>directed acyclic graph (DAG)</strong> before encoding.</p>
-<p>Each unique node is assigned an identifier. When the encoder
-encounters a repeated node, it emits a reference to its identifier
-instead of encoding it again.</p>
-<p>During decoding, the identifier is resolved to the corresponding
-subtree, reconstructing the shared structure.</p>
-<p>Folding is optional; it saves space without changing the logical
-value.</p>
-<hr />
-<h2 id="stream-format"><strong>14.8 Stream format</strong></h2>
-<p>A minimal canonical bitstream consists of:</p>
-<ol type="1">
-<li><strong>Header</strong> – type hash (e.g., 8 bytes) identifying the
-canonical type.</li>
-<li><strong>Node count</strong> – integer <em>N</em> if DAG encoding is
-used.</li>
-<li><strong>Encoded data</strong> – concatenation of all fixed-length
-union codes and, if folded, node references.</li>
-</ol>
-<p>If two systems share the same canonical type table, the bitstream
-alone is enough to reconstruct the original value.</p>
-<hr />
-<h2 id="implementation-sketch"><strong>14.9 Implementation
-sketch</strong></h2>
-<p>A compact encoder can be written as follows:</p>
-<pre><code>procedure encode(node):
-    if node.arity == 0:
-        return
-    if node.arity == 1:
-        write_bits(code_for(node.state, node.tag))
-        encode(node.child[0])
-    else:
-        for each child in node.children:
-            encode(child)</code></pre>
-<p>The corresponding decoder reverses the process. Both procedures
-require only the canonical type tables and simple bit operations.</p>
-<hr />
-<h2 id="determinism-and-equality"><strong>14.10 Determinism and
-equality</strong></h2>
-<p>Because encoding is fully determined by the canonical type and field
-order, two equal values always produce identical bit sequences.
-Conversely, decoding the same bit sequence always yields the same
-tree.</p>
-<p>This property allows equality comparison by direct byte comparison of
-serialized forms, without traversing the trees in memory.</p>
-<hr />
-<h2 id="summary-12"><strong>14.11 Summary</strong></h2>
-<ul>
-<li>Every type’s canonical automaton defines a unique bit-level grammar
-for its values.</li>
-<li>Products emit no bits; unions emit fixed-length variant codes.</li>
-<li>The number of bits required for each state depends only on the
-number of variants in that state.</li>
-<li>Optional DAG folding eliminates repeated subtrees.</li>
-<li>The resulting bitstream is compact, deterministic, and
-machine-independent.</li>
-</ul>
-<h1 id="chapter-15-optimization-and-folding">Chapter 15 — Optimization
-and Folding</h1>
-<h2 id="purpose-6"><strong>15.1 Purpose</strong></h2>
-<p>Optimization in the k compiler is the process of simplifying
-functions without changing their meaning. The goal is to make the
-generated code smaller, faster, and easier to verify. Because k is
-purely functional and has no side effects, optimizations are safe
-whenever the simplified function is equivalent to the original one.</p>
-<p>This chapter describes a few basic optimizations that follow directly
-from the semantics introduced earlier.</p>
-<hr />
-<h2 id="constant-folding"><strong>15.2 Constant folding</strong></h2>
-<p>A <strong>constant</strong> is a function that ignores its input and
-always produces the same value. If a composition of functions can be
-evaluated entirely at compile time, it can be replaced by a single
-constant function.</p>
-<p>Example:</p>
-<pre><code>true_bool  = {{ } true} $bool;
-not_true   = (true_bool neg);</code></pre>
-<p>The compiler observes that <code>(true_bool neg)</code> always yields
-<code>false_bool</code>, so it replaces it with a constant:</p>
-<pre><code>not_true = {{ } false} $bool;</code></pre>
-<p>Constant folding removes unnecessary runtime computation.</p>
-<hr />
-<h2 id="type-based-simplifications"><strong>15.3 Type-based
-simplifications</strong></h2>
-<p>Since type expressions act as identity functions defined only on
-specific values, they can be eliminated when redundant:</p>
-<pre><code>$bool $bool f   →  $bool f</code></pre>
-<p>If a function’s input or output type is already known from context,
-repeated checks can be omitted. The compiler ensures that at least one
-valid check remains to preserve correctness.</p>
-<hr />
-<h2 id="inlining"><strong>15.4 Inlining</strong></h2>
-<p>Inlining replaces a call to a small function by its body. It avoids
-the overhead of a function call and often exposes further
-simplifications.</p>
-<p>Example:</p>
-<pre><code>id = ();
-f  = (id g);</code></pre>
-<p>Because <code>id</code> is the identity function, <code>(id g)</code>
-is equivalent to <code>g</code>. Inlining removes the useless call.</p>
-<p>For larger functions, inlining is applied selectively—only when it
-shortens the resulting code or eliminates intermediate values.</p>
-<hr />
-<h2 id="dead-branch-elimination"><strong>15.5 Dead-branch
-elimination</strong></h2>
-<p>In a union composition <code>&lt;f, g&gt;</code>, if type analysis
-shows that the input type can only satisfy the first branch, the second
-branch can never be defined and is removed.</p>
-<p>Example:</p>
-<pre><code>$bool = &lt; {} true, {} false &gt;;
-f = $bool &lt; .true {{ } false} &gt;;</code></pre>
-<p>Here, since <code>$bool</code> restricts the input to only the two
-variants <code>true</code> and <code>false</code>, and the second
-variant <code>.false</code> is not handled, the compiler infers that
-<code>f</code> is undefined for <code>.false</code> and simplifies the
-code accordingly.</p>
-<p>Dead-branch elimination keeps the generated control flow minimal.</p>
-<hr />
-<h2 id="common-subexpression-elimination"><strong>15.6 Common
-subexpression elimination</strong></h2>
-<p>If the same partial function is applied multiple times to the same
-input, the result will always be the same. The compiler can compute it
-once and reuse the result.</p>
-<p>Example:</p>
-<pre><code>{ .x .y, .x .z }</code></pre>
-<p>Both fields start with the projection <code>.x</code>. The compiler
-computes <code>.x</code> once, stores the result, and reuses it for
-<code>.y</code> and <code>.z</code>. This optimization reduces repeated
-traversal of the same input structure.</p>
-<hr />
-<h2 id="canonical-folding"><strong>15.7 Canonical folding</strong></h2>
-<p>During evaluation, many values share identical subtrees. A
-<strong>folding pass</strong> replaces identical subtrees by shared
-nodes, forming a minimal DAG (directed acyclic graph).</p>
-<p>At compile time, folding may also apply to constant expressions. If
-two constant subtrees are identical, they are merged and stored as a
-single global node.</p>
-<p>This process ensures that structural equality corresponds to pointer
-equality: two values are identical if they share the same root node.</p>
-<hr />
-<h2 id="function-canonicalization"><strong>15.8 Function
-canonicalization</strong></h2>
-<p>Every function can be normalized by expanding all type aliases,
-inlining trivial definitions, and folding identical subfunctions. The
-normalized form of a function depends only on its semantics, not on the
-way it was written.</p>
-<p>A stable hash computed from this canonical representation serves as a
-permanent identifier for the function, just as type hashes identify
-canonical types.</p>
-<p>This property is essential for the schema registry described in the
-next chapter.</p>
-<hr />
-<h2 id="runtime-simplifications"><strong>15.9 Runtime
-simplifications</strong></h2>
-<p>At runtime, additional micro-optimizations are possible:</p>
-<ul>
-<li><strong>Arena reuse:</strong> allocate nodes in a memory region that
-is cleared after each function call.</li>
-<li><strong>Hash-consing:</strong> maintain a small table of recently
-created nodes to reuse identical ones automatically.</li>
-<li><strong>Shortcut constants:</strong> return pointers to global
-constants instead of allocating new copies for unit or boolean
-values.</li>
-</ul>
-<p>Such optimizations reduce memory usage without changing program
-behavior.</p>
-<hr />
-<h2 id="equivalence-and-correctness"><strong>15.10 Equivalence and
-correctness</strong></h2>
-<p>Each optimization must preserve <em>semantic equivalence</em>: for
-every input, the optimized function must be defined for exactly the same
-values and must return the same result when defined.</p>
-<p>Because k’s semantics are purely functional, equivalence can be
-tested mechanically by comparing evaluation results on all finite inputs
-of a small type, or by structural reasoning when types are infinite.</p>
-<hr />
-<h2 id="summary-13"><strong>15.11 Summary</strong></h2>
-<ul>
-<li>Optimization in k relies on algebraic properties of pure
-functions.</li>
-<li>Common transformations include constant folding, inlining,
-dead-branch elimination, and subexpression reuse.</li>
-<li>Folding shared subtrees yields compact DAG representations of
-values.</li>
-<li>Canonical function forms allow stable hashing and reproducible
-compilation results.</li>
-<li>All optimizations preserve exact semantic behavior.</li>
-</ul>
-<h1 id="chapter-16-toward-a-universal-schema-registry">Chapter 16 —
-Toward a Universal Schema Registry</h1>
-<h2 id="motivation-1"><strong>16.1 Motivation</strong></h2>
-<p>Every canonical type and function in k has a unique structural form
-and a stable hash. These hashes can serve as global identifiers. A
-registry that maps such identifiers to definitions allows programs and
-systems to exchange schemas and functions safely and reproducibly.</p>
-<hr />
-<h2 id="basic-structure"><strong>16.2 Basic structure</strong></h2>
-<p>A schema registry stores entries of two kinds:</p>
-<table>
-<colgroup>
-<col style="width: 16%" />
-<col style="width: 83%" />
-</colgroup>
-<thead>
-<tr>
-<th>Kind</th>
-<th>Example content</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td><strong>Type</strong></td>
-<td>canonical automaton text for a type hash</td>
-</tr>
-<tr>
-<td><strong>Function</strong></td>
-<td>canonical IR or serialized representation for a function hash</td>
-</tr>
-</tbody>
-</table>
-<p>Each entry is immutable. New versions are added as new hashes.</p>
-<hr />
-<h2 id="key-operations"><strong>16.3 Key operations</strong></h2>
-<ol type="1">
-<li><strong>Lookup by hash</strong> — return the canonical
-definition.</li>
-<li><strong>Lookup by shape</strong> — search for functions with given
-input/output type hashes.</li>
-<li><strong>Verification</strong> — ensure that two parties share the
-same canonical form before exchanging values.</li>
-</ol>
-<p>These operations can be implemented as simple key–value queries.</p>
-<hr />
-<h2 id="example-format"><strong>16.4 Example format</strong></h2>
-<p>A minimal JSON entry:</p>
-<div class="sourceCode" id="cb119"><pre
-class="sourceCode json"><code class="sourceCode json"><span id="cb119-1"><a href="#cb119-1" aria-hidden="true" tabindex="-1"></a><span class="fu">{</span></span>
-<span id="cb119-2"><a href="#cb119-2" aria-hidden="true" tabindex="-1"></a>  <span class="dt">&quot;hash&quot;</span><span class="fu">:</span> <span class="st">&quot;C0ABCDEF&quot;</span><span class="fu">,</span></span>
-<span id="cb119-3"><a href="#cb119-3" aria-hidden="true" tabindex="-1"></a>  <span class="dt">&quot;kind&quot;</span><span class="fu">:</span> <span class="st">&quot;type&quot;</span><span class="fu">,</span></span>
-<span id="cb119-4"><a href="#cb119-4" aria-hidden="true" tabindex="-1"></a>  <span class="dt">&quot;definition&quot;</span><span class="fu">:</span> <span class="st">&quot;$C0=&lt;C0</span><span class="ch">\&quot;</span><span class="st">0</span><span class="ch">\&quot;</span><span class="st">,C0</span><span class="ch">\&quot;</span><span class="st">1</span><span class="ch">\&quot;</span><span class="st">,C1</span><span class="ch">\&quot;</span><span class="st">_</span><span class="ch">\&quot;</span><span class="st">&gt;;$C1={};&quot;</span></span>
-<span id="cb119-5"><a href="#cb119-5" aria-hidden="true" tabindex="-1"></a><span class="fu">}</span></span></code></pre></div>
-<p>or for a function:</p>
-<div class="sourceCode" id="cb120"><pre
-class="sourceCode json"><code class="sourceCode json"><span id="cb120-1"><a href="#cb120-1" aria-hidden="true" tabindex="-1"></a><span class="fu">{</span></span>
-<span id="cb120-2"><a href="#cb120-2" aria-hidden="true" tabindex="-1"></a>  <span class="dt">&quot;hash&quot;</span><span class="fu">:</span> <span class="st">&quot;F7B1A2&quot;</span><span class="fu">,</span></span>
-<span id="cb120-3"><a href="#cb120-3" aria-hidden="true" tabindex="-1"></a>  <span class="dt">&quot;kind&quot;</span><span class="fu">:</span> <span class="st">&quot;function&quot;</span><span class="fu">,</span></span>
-<span id="cb120-4"><a href="#cb120-4" aria-hidden="true" tabindex="-1"></a>  <span class="dt">&quot;input&quot;</span><span class="fu">:</span> <span class="st">&quot;C0ABCDEF&quot;</span><span class="fu">,</span></span>
-<span id="cb120-5"><a href="#cb120-5" aria-hidden="true" tabindex="-1"></a>  <span class="dt">&quot;output&quot;</span><span class="fu">:</span> <span class="st">&quot;C9FFF1&quot;</span><span class="fu">,</span></span>
-<span id="cb120-6"><a href="#cb120-6" aria-hidden="true" tabindex="-1"></a>  <span class="dt">&quot;ir&quot;</span><span class="fu">:</span> <span class="st">&quot;SEQ [PROJECT x, CONST true]&quot;</span></span>
-<span id="cb120-7"><a href="#cb120-7" aria-hidden="true" tabindex="-1"></a><span class="fu">}</span></span></code></pre></div>
-<hr />
-<h2 id="uses"><strong>16.5 Uses</strong></h2>
-<ul>
-<li>Preventing schema mismatches in distributed systems.</li>
-<li>Deduplicating identical definitions across projects.</li>
-<li>Enabling reproducible builds where all types and functions are
-referenced by hash.</li>
-</ul>
-<hr />
-<h2 id="summary-14"><strong>16.6 Summary</strong></h2>
-<ul>
-<li>Canonical types and functions can be globally identified by stable
-hashes.</li>
-<li>A simple registry provides lookup and verification of these
-definitions.</li>
-<li>Such registries make k programs portable, self-describing, and safe
-to share between systems.</li>
-</ul>
-<h1 id="appendix-a-implementing-a-prototype-compiler-in-python">Appendix
-A — Implementing a Prototype Compiler in Python</h1>
-<h2 id="a.1-purpose"><strong>A.1 Purpose</strong></h2>
-<p>This appendix outlines how to implement a simple, working prototype
-of the k compiler in Python. The goal is to let the reader experiment
-with parsing, type normalization, and LLVM code generation using only
-standard tools and a few small libraries. The prototype does not need to
-support optimization or a full runtime—only the basic translation
-pipeline.</p>
-<hr />
-<h2 id="a.2-required-environment"><strong>A.2 Required
-environment</strong></h2>
-<p>Install:</p>
-<div class="sourceCode" id="cb121"><pre
-class="sourceCode bash"><code class="sourceCode bash"><span id="cb121-1"><a href="#cb121-1" aria-hidden="true" tabindex="-1"></a><span class="ex">python3</span> <span class="at">-m</span> venv kenv</span>
-<span id="cb121-2"><a href="#cb121-2" aria-hidden="true" tabindex="-1"></a><span class="bu">source</span> kenv/bin/activate</span>
-<span id="cb121-3"><a href="#cb121-3" aria-hidden="true" tabindex="-1"></a><span class="ex">pip</span> install llvmlite</span></code></pre></div>
-<p><code>llvmlite</code> provides an interface to LLVM for code
-generation. No additional dependencies are required.</p>
-<hr />
-<h2 id="a.3-recommended-directory-structure"><strong>A.3 Recommended
-directory structure</strong></h2>
-<pre><code>k-compiler/
- ├── main.py             # command-line driver
- ├── parser.py           # converts source text to AST
- ├── types.py            # canonical type construction
- ├── normalize.py        # filter resolution and typing
- ├── ir.py               # intermediate representation
- ├── codegen.py          # translation from IR to LLVM
- ├── runtime.ll          # minimal runtime in LLVM
- └── examples/           # sample k programs</code></pre>
-<p>Each module is small and focused on one task.</p>
-<hr />
-<h2 id="a.4-the-ast"><strong>A.4 The AST</strong></h2>
-<p>Represent the language syntax with Python classes:</p>
-<div class="sourceCode" id="cb123"><pre
-class="sourceCode python"><code class="sourceCode python"><span id="cb123-1"><a href="#cb123-1" aria-hidden="true" tabindex="-1"></a><span class="kw">class</span> Expr: <span class="cf">pass</span></span>
-<span id="cb123-2"><a href="#cb123-2" aria-hidden="true" tabindex="-1"></a></span>
-<span id="cb123-3"><a href="#cb123-3" aria-hidden="true" tabindex="-1"></a><span class="kw">class</span> Composition(Expr):</span>
-<span id="cb123-4"><a href="#cb123-4" aria-hidden="true" tabindex="-1"></a>    <span class="kw">def</span> <span class="fu">__init__</span>(<span class="va">self</span>, parts): <span class="va">self</span>.parts <span class="op">=</span> parts</span>
-<span id="cb123-5"><a href="#cb123-5" aria-hidden="true" tabindex="-1"></a></span>
-<span id="cb123-6"><a href="#cb123-6" aria-hidden="true" tabindex="-1"></a><span class="kw">class</span> Product(Expr):</span>
-<span id="cb123-7"><a href="#cb123-7" aria-hidden="true" tabindex="-1"></a>    <span class="kw">def</span> <span class="fu">__init__</span>(<span class="va">self</span>, fields): <span class="va">self</span>.fields <span class="op">=</span> fields  <span class="co"># [(label, expr), ...]</span></span>
-<span id="cb123-8"><a href="#cb123-8" aria-hidden="true" tabindex="-1"></a></span>
-<span id="cb123-9"><a href="#cb123-9" aria-hidden="true" tabindex="-1"></a><span class="kw">class</span> Union(Expr):</span>
-<span id="cb123-10"><a href="#cb123-10" aria-hidden="true" tabindex="-1"></a>    <span class="kw">def</span> <span class="fu">__init__</span>(<span class="va">self</span>, options): <span class="va">self</span>.options <span class="op">=</span> options  <span class="co"># [expr, ...]</span></span>
-<span id="cb123-11"><a href="#cb123-11" aria-hidden="true" tabindex="-1"></a></span>
-<span id="cb123-12"><a href="#cb123-12" aria-hidden="true" tabindex="-1"></a><span class="kw">class</span> Projection(Expr):</span>
-<span id="cb123-13"><a href="#cb123-13" aria-hidden="true" tabindex="-1"></a>    <span class="kw">def</span> <span class="fu">__init__</span>(<span class="va">self</span>, label): <span class="va">self</span>.label <span class="op">=</span> label</span>
-<span id="cb123-14"><a href="#cb123-14" aria-hidden="true" tabindex="-1"></a></span>
-<span id="cb123-15"><a href="#cb123-15" aria-hidden="true" tabindex="-1"></a><span class="kw">class</span> Constant(Expr):</span>
-<span id="cb123-16"><a href="#cb123-16" aria-hidden="true" tabindex="-1"></a>    <span class="kw">def</span> <span class="fu">__init__</span>(<span class="va">self</span>, name): <span class="va">self</span>.name <span class="op">=</span> name</span></code></pre></div>
-<p>The parser builds these objects from source text.</p>
-<hr />
-<h2 id="a.5-type-normalization"><strong>A.5 Type
-normalization</strong></h2>
-<p>Maintain canonical type states as small Python objects:</p>
-<div class="sourceCode" id="cb124"><pre
-class="sourceCode python"><code class="sourceCode python"><span id="cb124-1"><a href="#cb124-1" aria-hidden="true" tabindex="-1"></a><span class="kw">class</span> TypeState:</span>
-<span id="cb124-2"><a href="#cb124-2" aria-hidden="true" tabindex="-1"></a>    <span class="kw">def</span> <span class="fu">__init__</span>(<span class="va">self</span>, kind, transitions):</span>
-<span id="cb124-3"><a href="#cb124-3" aria-hidden="true" tabindex="-1"></a>        <span class="va">self</span>.kind <span class="op">=</span> kind      <span class="co"># &#39;product&#39; or &#39;union&#39;</span></span>
-<span id="cb124-4"><a href="#cb124-4" aria-hidden="true" tabindex="-1"></a>        <span class="va">self</span>.transitions <span class="op">=</span> transitions  <span class="co"># [(label, next_state)]</span></span></code></pre></div>
-<p>Normalization expands type aliases and assigns numeric state IDs
-(<code>C0</code>, <code>C1</code>, …). For a prototype, a simple
-structural hash (using <code>json.dumps</code>) can serve as the
-canonical identifier.</p>
-<hr />
-<h2 id="a.6-intermediate-representation"><strong>A.6 Intermediate
-representation</strong></h2>
-<p>Represent IR instructions as simple tuples or small classes:</p>
-<div class="sourceCode" id="cb125"><pre
-class="sourceCode python"><code class="sourceCode python"><span id="cb125-1"><a href="#cb125-1" aria-hidden="true" tabindex="-1"></a><span class="kw">class</span> Project:  <span class="kw">def</span> <span class="fu">__init__</span>(<span class="va">self</span>, label): <span class="va">self</span>.label <span class="op">=</span> label</span>
-<span id="cb125-2"><a href="#cb125-2" aria-hidden="true" tabindex="-1"></a><span class="kw">class</span> Const:    <span class="kw">def</span> <span class="fu">__init__</span>(<span class="va">self</span>, node):  <span class="va">self</span>.node <span class="op">=</span> node</span>
-<span id="cb125-3"><a href="#cb125-3" aria-hidden="true" tabindex="-1"></a><span class="kw">class</span> Seq:      <span class="kw">def</span> <span class="fu">__init__</span>(<span class="va">self</span>, parts): <span class="va">self</span>.parts <span class="op">=</span> parts</span>
-<span id="cb125-4"><a href="#cb125-4" aria-hidden="true" tabindex="-1"></a><span class="kw">class</span> UnionIR:  <span class="kw">def</span> <span class="fu">__init__</span>(<span class="va">self</span>, parts): <span class="va">self</span>.parts <span class="op">=</span> parts</span>
-<span id="cb125-5"><a href="#cb125-5" aria-hidden="true" tabindex="-1"></a><span class="kw">class</span> ProductIR:<span class="kw">def</span> <span class="fu">__init__</span>(<span class="va">self</span>, fields):<span class="va">self</span>.fields <span class="op">=</span> fields</span></code></pre></div>
-<p>A recursive function converts an AST expression into IR following
-Chapter 10.</p>
-<hr />
-<h2 id="a.7-generating-llvm-code"><strong>A.7 Generating LLVM
-code</strong></h2>
-<p>Using <code>llvmlite.ir</code>, create one LLVM function per compiled
-function:</p>
-<div class="sourceCode" id="cb126"><pre
-class="sourceCode python"><code class="sourceCode python"><span id="cb126-1"><a href="#cb126-1" aria-hidden="true" tabindex="-1"></a><span class="im">from</span> llvmlite <span class="im">import</span> ir</span>
-<span id="cb126-2"><a href="#cb126-2" aria-hidden="true" tabindex="-1"></a></span>
-<span id="cb126-3"><a href="#cb126-3" aria-hidden="true" tabindex="-1"></a>mod <span class="op">=</span> ir.Module(name<span class="op">=</span><span class="st">&quot;k&quot;</span>)</span>
-<span id="cb126-4"><a href="#cb126-4" aria-hidden="true" tabindex="-1"></a></span>
-<span id="cb126-5"><a href="#cb126-5" aria-hidden="true" tabindex="-1"></a><span class="co"># LLVM type definitions</span></span>
-<span id="cb126-6"><a href="#cb126-6" aria-hidden="true" tabindex="-1"></a>KNodePtr <span class="op">=</span> ir.PointerType(ir.IntType(<span class="dv">8</span>))</span>
-<span id="cb126-7"><a href="#cb126-7" aria-hidden="true" tabindex="-1"></a>KVal  <span class="op">=</span> ir.LiteralStructType([KNodePtr])</span>
-<span id="cb126-8"><a href="#cb126-8" aria-hidden="true" tabindex="-1"></a>KOpt  <span class="op">=</span> ir.LiteralStructType([ir.IntType(<span class="dv">1</span>), KVal])</span>
-<span id="cb126-9"><a href="#cb126-9" aria-hidden="true" tabindex="-1"></a></span>
-<span id="cb126-10"><a href="#cb126-10" aria-hidden="true" tabindex="-1"></a><span class="kw">def</span> emit_function(name, ir_expr):</span>
-<span id="cb126-11"><a href="#cb126-11" aria-hidden="true" tabindex="-1"></a>    fn_type <span class="op">=</span> ir.FunctionType(KOpt, [KVal])</span>
-<span id="cb126-12"><a href="#cb126-12" aria-hidden="true" tabindex="-1"></a>    fn <span class="op">=</span> ir.Function(mod, fn_type, name<span class="op">=</span>name)</span>
-<span id="cb126-13"><a href="#cb126-13" aria-hidden="true" tabindex="-1"></a>    block <span class="op">=</span> fn.append_basic_block(<span class="st">&#39;entry&#39;</span>)</span>
-<span id="cb126-14"><a href="#cb126-14" aria-hidden="true" tabindex="-1"></a>    builder <span class="op">=</span> ir.IRBuilder(block)</span>
-<span id="cb126-15"><a href="#cb126-15" aria-hidden="true" tabindex="-1"></a>    <span class="co"># translate ir_expr recursively into builder calls</span></span>
-<span id="cb126-16"><a href="#cb126-16" aria-hidden="true" tabindex="-1"></a>    builder.ret(ir.Constant(KOpt, (ir.Constant(ir.IntType(<span class="dv">1</span>), <span class="dv">0</span>),</span>
-<span id="cb126-17"><a href="#cb126-17" aria-hidden="true" tabindex="-1"></a>                                   ir.Constant(KVal, ir.Constant(KNodePtr, <span class="va">None</span>)))))</span></code></pre></div>
-<p>The translation patterns follow those described in Chapter 12. Each
-IR node is emitted as a call or conditional block using
-<code>builder.call</code>, <code>builder.if_then</code>, and so on.</p>
-<hr />
-<h2 id="a.8-minimal-runtime"><strong>A.8 Minimal runtime</strong></h2>
-<p>Write a minimal <code>runtime.ll</code> that defines stubs for:</p>
-<div class="sourceCode" id="cb127"><pre
-class="sourceCode llvm"><code class="sourceCode llvm"><span id="cb127-1"><a href="#cb127-1" aria-hidden="true" tabindex="-1"></a><span class="kw">declare</span> <span class="fu">%KOpt</span> <span class="fu">@k_project</span>(<span class="fu">%KVal</span> <span class="fu">%v</span>, <span class="dt">i32</span> <span class="fu">%label</span>)</span>
-<span id="cb127-2"><a href="#cb127-2" aria-hidden="true" tabindex="-1"></a><span class="kw">declare</span> <span class="fu">%KVal</span> <span class="fu">@k_make_product</span>(<span class="dt">i32</span> <span class="fu">%state</span>, <span class="dt">i32</span> <span class="fu">%n</span>, <span class="fu">%KVal</span>* <span class="fu">%children</span>)</span>
-<span id="cb127-3"><a href="#cb127-3" aria-hidden="true" tabindex="-1"></a><span class="kw">declare</span> <span class="fu">%KVal</span> <span class="fu">@k_make_union</span>(<span class="dt">i32</span> <span class="fu">%state</span>, <span class="dt">i32</span> <span class="fu">%tag</span>, <span class="fu">%KVal</span> <span class="fu">%child</span>)</span></code></pre></div>
-<p>These can simply return placeholder constants for testing. Later,
-they can be replaced with the real runtime implemented in C.</p>
-<hr />
-<h2 id="a.9-putting-it-together"><strong>A.9 Putting it
-together</strong></h2>
-<p>A small driver script (<code>main.py</code>) can compile a file and
-emit LLVM text:</p>
-<div class="sourceCode" id="cb128"><pre
-class="sourceCode python"><code class="sourceCode python"><span id="cb128-1"><a href="#cb128-1" aria-hidden="true" tabindex="-1"></a><span class="im">import</span> parser, normalize, ir, codegen</span>
-<span id="cb128-2"><a href="#cb128-2" aria-hidden="true" tabindex="-1"></a></span>
-<span id="cb128-3"><a href="#cb128-3" aria-hidden="true" tabindex="-1"></a><span class="kw">def</span> compile_file(path):</span>
-<span id="cb128-4"><a href="#cb128-4" aria-hidden="true" tabindex="-1"></a>    src <span class="op">=</span> <span class="bu">open</span>(path).read()</span>
-<span id="cb128-5"><a href="#cb128-5" aria-hidden="true" tabindex="-1"></a>    ast <span class="op">=</span> parser.parse(src)</span>
-<span id="cb128-6"><a href="#cb128-6" aria-hidden="true" tabindex="-1"></a>    typed <span class="op">=</span> normalize.process(ast)</span>
-<span id="cb128-7"><a href="#cb128-7" aria-hidden="true" tabindex="-1"></a>    ir_tree <span class="op">=</span> ir.from_ast(typed)</span>
-<span id="cb128-8"><a href="#cb128-8" aria-hidden="true" tabindex="-1"></a>    llvm_module <span class="op">=</span> codegen.emit(ir_tree)</span>
-<span id="cb128-9"><a href="#cb128-9" aria-hidden="true" tabindex="-1"></a>    <span class="bu">print</span>(<span class="bu">str</span>(llvm_module))</span></code></pre></div>
-<p>Run:</p>
-<div class="sourceCode" id="cb129"><pre
-class="sourceCode bash"><code class="sourceCode bash"><span id="cb129-1"><a href="#cb129-1" aria-hidden="true" tabindex="-1"></a><span class="ex">python</span> main.py examples/neg.k <span class="op">&gt;</span> neg.ll</span>
-<span id="cb129-2"><a href="#cb129-2" aria-hidden="true" tabindex="-1"></a><span class="fu">clang</span> <span class="at">-O2</span> neg.ll runtime.ll <span class="at">-o</span> neg</span></code></pre></div>
-<hr />
-<h2 id="a.10-suggested-extensions"><strong>A.10 Suggested
-extensions</strong></h2>
-<ol type="1">
-<li>Implement the runtime functions in Python for quick testing.</li>
-<li>Add a textual REPL that reads a k expression and prints its IR.</li>
-<li>Integrate a simple interpreter to compare interpreter and compiled
-results.</li>
-<li>Use hashing of canonical forms to name generated LLVM
-functions.</li>
-</ol>
-<hr />
-<h2 id="a.11-summary"><strong>A.11 Summary</strong></h2>
-<p>A prototype compiler can be realized in fewer than a thousand lines
-of Python. It can parse k definitions, construct canonical types,
-translate expressions into IR, and generate valid LLVM code. Such a
-prototype is enough to experiment with all ideas presented in this
-textbook and to verify the semantics of the k language in practice.</p>
-<hr />
-<h1
-id="appendix-b-incorporating-external-predefined-types-and-functions">Appendix
-B — Incorporating External Predefined Types and Functions</h1>
-<h2 id="b.1-purpose"><strong>B.1 Purpose</strong></h2>
-<p>The k language is intentionally minimal. Nevertheless, real systems
-often need to interact with data types and operations defined outside of
-k—for example, numeric values, text, or platform-specific constants.
-This appendix explains how external predefined types and functions can
-be introduced into a k compiler without changing the language
-itself.</p>
-<hr />
-<h2 id="b.2-external-types"><strong>B.2 External types</strong></h2>
-<p>An <strong>external type</strong> is a canonical type that is
-<em>not</em> expressed through k’s own product-and-union syntax but is
-known to the compiler through registration.</p>
-<p>Each external type has:</p>
-<table>
-<colgroup>
-<col style="width: 21%" />
-<col style="width: 78%" />
-</colgroup>
-<thead>
-<tr>
-<th>Field</th>
-<th>Description</th>
-</tr>
-</thead>
-<tbody>
-<tr>
-<td><strong>Name</strong></td>
-<td>symbolic name (e.g., <code>$int</code>, <code>$string</code>)</td>
-</tr>
-<tr>
-<td><strong>Hash</strong></td>
-<td>unique stable identifier, just like canonical types</td>
-</tr>
-<tr>
-<td><strong>Runtime kind</strong></td>
-<td>how the value is stored in memory (pointer, immediate integer,
-etc.)</td>
-</tr>
-<tr>
-<td><strong>Adapter functions</strong></td>
-<td>conversion between the external representation and the standard
-<code>KNode</code> tree</td>
-</tr>
-</tbody>
-</table>
-<p>Example registry entry:</p>
-<div class="sourceCode" id="cb130"><pre
-class="sourceCode json"><code class="sourceCode json"><span id="cb130-1"><a href="#cb130-1" aria-hidden="true" tabindex="-1"></a><span class="fu">{</span></span>
-<span id="cb130-2"><a href="#cb130-2" aria-hidden="true" tabindex="-1"></a>  <span class="dt">&quot;hash&quot;</span><span class="fu">:</span> <span class="st">&quot;E001&quot;</span><span class="fu">,</span></span>
-<span id="cb130-3"><a href="#cb130-3" aria-hidden="true" tabindex="-1"></a>  <span class="dt">&quot;kind&quot;</span><span class="fu">:</span> <span class="st">&quot;type&quot;</span><span class="fu">,</span></span>
-<span id="cb130-4"><a href="#cb130-4" aria-hidden="true" tabindex="-1"></a>  <span class="dt">&quot;external&quot;</span><span class="fu">:</span> <span class="kw">true</span><span class="fu">,</span></span>
-<span id="cb130-5"><a href="#cb130-5" aria-hidden="true" tabindex="-1"></a>  <span class="dt">&quot;name&quot;</span><span class="fu">:</span> <span class="st">&quot;$int&quot;</span><span class="fu">,</span></span>
-<span id="cb130-6"><a href="#cb130-6" aria-hidden="true" tabindex="-1"></a>  <span class="dt">&quot;runtime_kind&quot;</span><span class="fu">:</span> <span class="st">&quot;primitive_i64&quot;</span></span>
-<span id="cb130-7"><a href="#cb130-7" aria-hidden="true" tabindex="-1"></a><span class="fu">}</span></span></code></pre></div>
-<p>The compiler treats such a type as an atomic node, represented
-internally as a single <code>KNode</code> with <code>arity = 0</code>
-but tagged as <em>external</em>.</p>
-<hr />
-<h2 id="b.3-external-constructors"><strong>B.3 External
-constructors</strong></h2>
-<p>External types may provide special constructors or constants. For
-example, <code>$int</code> might include predefined constant
-functions:</p>
-<pre><code>zero  = {} $int;
-one   = {} $int;</code></pre>
-<p>At compile time these appear as constant functions returning fixed
-external nodes provided by the runtime.</p>
-<hr />
-<h2 id="b.4-external-functions"><strong>B.4 External
-functions</strong></h2>
-<p>External functions are partial functions implemented outside of k but
-declared inside a k program. They have known input and output types,
-possibly external.</p>
-<p>Declaration syntax:</p>
-<pre><code>extern add : $int $int → $int;
-extern less : $int $int → $bool;</code></pre>
-<p>At compile time the compiler records the signature and associates it
-with a runtime symbol name such as <code>k_ext_add</code>.</p>
-<p>When generating code, each external call becomes a standard function
-call following the ABI:</p>
-<div class="sourceCode" id="cb133"><pre
-class="sourceCode llvm"><code class="sourceCode llvm"><span id="cb133-1"><a href="#cb133-1" aria-hidden="true" tabindex="-1"></a><span class="kw">declare</span> <span class="fu">%KOpt</span> <span class="fu">@k_ext_add</span>(<span class="fu">%KVal</span> <span class="fu">%a</span>, <span class="fu">%KVal</span> <span class="fu">%b</span>)</span></code></pre></div>
-<p>The runtime library provides these implementations in a native
-language (C, C++, Rust, etc.).</p>
-<hr />
-<h2 id="b.5-integration-with-canonical-types"><strong>B.5 Integration
-with canonical types</strong></h2>
-<p>External types are integrated into the canonical system as <em>leaf
-states</em>. They can appear as components in products or unions just
-like built-in ones.</p>
-<p>Example:</p>
-<pre><code>$point = { $int x, $int y };</code></pre>
-<p>Canonical form:</p>
-<pre><code>$C0 = { C1 &quot;x&quot;, C1 &quot;y&quot; };
-$C1 = external $int;</code></pre>
-<p>This allows normal serialization and type comparison; the external
-leaf is treated as opaque but identified by its hash.</p>
-<hr />
-<h2 id="b.6-serialization-and-external-values"><strong>B.6 Serialization
-and external values</strong></h2>
-<p>During serialization, an external node is encoded by:</p>
-<ol type="1">
-<li>Its type hash (to indicate which external kind it represents).</li>
-<li>A binary blob produced by a runtime-supplied encoder for that
-type.</li>
-</ol>
-<p>Deserialization reverses the process using the corresponding decoder.
-All external codecs must be deterministic and version-stable to preserve
-canonical equality.</p>
-<hr />
-<h2 id="b.7-example"><strong>B.7 Example</strong></h2>
-<p>Suppose we introduce <code>$int</code> and external function
-<code>add</code>:</p>
-<pre><code>$pair_int = { $int a, $int b };
-sum = { .a x, .b y } (add x y);</code></pre>
-<p>The compiler generates code that:</p>
-<ul>
-<li>projects fields <code>.a</code> and <code>.b</code>,</li>
-<li>passes them as <code>KVal</code> pointers to
-<code>@k_ext_add</code>,</li>
-<li>and returns the result as a new <code>$int</code> node.</li>
-</ul>
-<p>All logic outside arithmetic remains standard k code.</p>
-<hr />
-<h2 id="b.8-practical-implementation"><strong>B.8 Practical
-implementation</strong></h2>
-<p>In a Python prototype:</p>
-<div class="sourceCode" id="cb137"><pre
-class="sourceCode python"><code class="sourceCode python"><span id="cb137-1"><a href="#cb137-1" aria-hidden="true" tabindex="-1"></a>EXTERNAL_TYPES <span class="op">=</span> {</span>
-<span id="cb137-2"><a href="#cb137-2" aria-hidden="true" tabindex="-1"></a>    <span class="st">&quot;$int&quot;</span>: {<span class="st">&quot;hash&quot;</span>: <span class="st">&quot;E001&quot;</span>, <span class="st">&quot;kind&quot;</span>: <span class="st">&quot;external&quot;</span>, <span class="st">&quot;runtime_kind&quot;</span>: <span class="st">&quot;primitive_i64&quot;</span>}</span>
-<span id="cb137-3"><a href="#cb137-3" aria-hidden="true" tabindex="-1"></a>}</span>
-<span id="cb137-4"><a href="#cb137-4" aria-hidden="true" tabindex="-1"></a></span>
-<span id="cb137-5"><a href="#cb137-5" aria-hidden="true" tabindex="-1"></a>EXTERNAL_FUNCS <span class="op">=</span> {</span>
-<span id="cb137-6"><a href="#cb137-6" aria-hidden="true" tabindex="-1"></a>    <span class="st">&quot;add&quot;</span>:  {<span class="st">&quot;inputs&quot;</span>: [<span class="st">&quot;$int&quot;</span>, <span class="st">&quot;$int&quot;</span>], <span class="st">&quot;output&quot;</span>: <span class="st">&quot;$int&quot;</span>, <span class="st">&quot;symbol&quot;</span>: <span class="st">&quot;k_ext_add&quot;</span>},</span>
-<span id="cb137-7"><a href="#cb137-7" aria-hidden="true" tabindex="-1"></a>    <span class="st">&quot;less&quot;</span>: {<span class="st">&quot;inputs&quot;</span>: [<span class="st">&quot;$int&quot;</span>, <span class="st">&quot;$int&quot;</span>], <span class="st">&quot;output&quot;</span>: <span class="st">&quot;$bool&quot;</span>, <span class="st">&quot;symbol&quot;</span>: <span class="st">&quot;k_ext_less&quot;</span>}</span>
-<span id="cb137-8"><a href="#cb137-8" aria-hidden="true" tabindex="-1"></a>}</span></code></pre></div>
-<p>During code generation, when a call refers to an external function,
-the compiler emits a call to the symbol given in the table.</p>
-<hr />
-<h2 id="b.9-summary"><strong>B.9 Summary</strong></h2>
-<ul>
-<li>External predefined types extend k without altering its core
-semantics.</li>
-<li>They are registered with hashes and treated as atomic nodes.</li>
-<li>External functions follow the same calling convention as normal
-ones.</li>
-<li>Serialization of external values uses type-specific codecs.</li>
-<li>This mechanism allows integration of native computations (numbers,
-strings, system data) while preserving the purity and determinism of the
-k language.</li>
-</ul>
-<hr />