@fraczak/k 6.1.2 → 6.2.0

package/{test-repl.mjs → tests/test-repl.mjs}

@@ -16,9 +16,9 @@ import {
   isMainEntrypoint,
   lineHasExplicitContinuation,
   lineTerminatesSnippet
-} from "./repl.mjs";
-import { decodeObject, objectToFunction } from "./object.mjs";
-import { Product } from "./Value.mjs";
+} from "../repl.mjs";
+import { decodeObject, objectToFunction } from "../object.mjs";
+import { Product } from "../Value.mjs";
 
 const state = createState();
 
@@ -90,6 +90,7 @@ await assert.rejects(
 
 const tmpDir = fs.mkdtempSync(path.join(os.tmpdir(), "k-repl-"));
 const libPath = path.join(tmpDir, "session.klib");
+const recursiveLibPath = path.join(tmpDir, "recursive.klib");
 const koPath = path.join(tmpDir, "succ.ko");
 const sourcePath = path.join(tmpDir, "session.k");
 const codecPath = path.join(tmpDir, "bool-codec.mjs");
@@ -97,6 +98,23 @@ const symlinkPath = path.resolve(".test-k-repl-link");
 output = await evaluateInput(`:klib ${libPath}`, state);
 assert.equal(output[0], `saved ${libPath}`);
 
+const recursiveState = createState();
+await evaluateInput(":type $ nat = < {}_, nat 0, nat 1 >;", recursiveState);
+await evaluateInput(":rel 0? = $ nat < / _ {}|0, / 0 0? >;", recursiveState);
+const staleZeroHash = recursiveState.relAliases["0?"];
+await evaluateInput(":rel 0? = $ nat < / _ {}|_, / 0 0? >;", recursiveState);
+const zeroHash = recursiveState.relAliases["0?"];
+assert.notEqual(zeroHash, staleZeroHash);
+await evaluateInput("{}|_|0|0 $nat", recursiveState);
+assert.deepEqual(
+  Object.keys(recursiveState.rels).sort(),
+  [staleZeroHash, zeroHash].sort()
+);
+output = await evaluateInput(`:klib ${recursiveLibPath}`, recursiveState);
+assert.equal(output[0], `saved ${recursiveLibPath}`);
+const recursiveLibrary = JSON.parse(fs.readFileSync(recursiveLibPath, "utf8"));
+assert.deepEqual(Object.keys(recursiveLibrary.rels), [zeroHash]);
+
 completions = completeInput(`:load ${tmpDir}/ses`, state)[0];
 assert(completions.includes(`:load ${libPath}`));
 completions = completeInput(`:load --no-alias ${tmpDir}/ses`, state)[0];
@@ -176,7 +194,7 @@ assert.equal(output[0], `input ${utf8State.typeAliases.string} using utf8: enter
 output = await evaluateInput("hello", utf8State);
 assert.match(output[0], /utf8: hello/);
 
-const replPath = fileURLToPath(new URL("./repl.mjs", import.meta.url));
+const replPath = fileURLToPath(new URL("../repl.mjs", import.meta.url));
 try {
   fs.rmSync(symlinkPath, { force: true });
 } catch {}

package/{test.mjs → tests/test.mjs}

@@ -1,4 +1,4 @@
-import k from "./index.mjs";
+import k from "../index.mjs";
 
 [
   [{"unit": {}}, "()"],

package/DOCS/a.html

@@ -1,398 +0,0 @@
-<h1 id="patterns-and-typed-values">Patterns And Typed Values</h1>
-<h2 id="abstract">Abstract</h2>
-<p>This note proposes a semantic foundation for <code>k</code> patterns,
-types, typed values, and polymorphic values. The central point is that a
-value in <code>k</code> is not a bare tree: it exists only in the
-context of a type. Accordingly, a pattern denotes a set of types, and
-therefore also a set of <strong>typed</strong> values, not a set of raw
-trees. This distinction is essential for reasoning about equality,
-polymorphism, and binary serialization with DAG compression.</p>
-<h2 id="introduction">1. Introduction</h2>
-<p>The <code>k</code> language manipulates algebraic values built from
-products and unions. At first sight one may be tempted to define a value
-simply as a rooted labeled tree and then define types as sets of such
-trees. For <code>k</code>, this is not the right semantic level.</p>
-<p>Two trees with the same shape but belonging to different types are
-different values. Type is part of value identity.</p>
-<p>This leads to the following semantic ladder:</p>
-<ul>
-<li>a <strong>type</strong> denotes a set of typed values,</li>
-<li>a <strong>pattern</strong> denotes a set of types,</li>
-<li>therefore a <strong>pattern</strong> also denotes a set of typed
-values,</li>
-<li>a <strong>polymorphic value</strong> is a pattern together with a
-typed value compatible with that pattern.</li>
-</ul>
-<p>The rest of this note makes these notions precise.</p>
-<h2 id="types">2. Types</h2>
-<p>A <strong>type graph</strong> is a finite rooted directed graph with
-labeled edges. Each node is one of:</p>
-<ul>
-<li><code>product</code>,</li>
-<li><code>union</code>.</li>
-</ul>
-<p>For a product node, outgoing edge labels are field names. For a union
-node, outgoing edge labels are tags. Edges are locally unique by
-label.</p>
-<p>The graph may be cyclic, which allows recursive types.</p>
-<p>Two type graphs that are equivalent as regular tree languages may be
-identified. For types, minimization by bisimulation is appropriate.</p>
-<h3 id="trees-accepted-by-a-type">2.1. Trees accepted by a type</h3>
-<p>Let <code>Tree(T)</code> denote the set of rooted value trees
-accepted by a type graph <code>T</code>. Acceptance is defined in the
-standard way:</p>
-<ul>
-<li>a product tree is accepted by a product node when its fields match
-the outgoing labels of that node and each child tree is accepted by the
-corresponding target node,</li>
-<li>a union tree is accepted by a union node when it chooses exactly one
-outgoing tag and the child tree is accepted by the corresponding target
-node.</li>
-</ul>
-<h2 id="typed-values">3. Typed Values</h2>
-<p>A <strong>typed value</strong> is a pair</p>
-<pre class="text"><code>(T, t)</code></pre>
-<p>where:</p>
-<ul>
-<li><code>T</code> is a type graph,</li>
-<li><code>t ∈ Tree(T)</code>.</li>
-</ul>
-<p>Thus a value is intrinsically typed. The tree <code>t</code> is only
-a representation of the value; it is not, by itself, a semantic value of
-the language.</p>
-<p>We write:</p>
-<pre class="text"><code>Val(T) = { (T, t) : t ∈ Tree(T) }.</code></pre>
-<h3 id="identity-of-typed-values">3.1. Identity of typed values</h3>
-<p>Typed values are intensional with respect to the type:</p>
-<pre class="text"><code>(T, t) ≠ (U, t)    whenever T ≠ U.</code></pre>
-<p>Even when the same raw tree <code>t</code> is accepted by both
-<code>T</code> and <code>U</code>, the two typed values are
-different.</p>
-<p>This point is essential for serialization: the identity of a value
-cannot be recovered from the raw tree alone.</p>
-<h2 id="patterns">4. Patterns</h2>
-<p>A <strong>pattern graph</strong> is a finite rooted directed graph
-with labeled edges. Each node carries:</p>
-<ul>
-<li>a node kind:
-<ul>
-<li><code>unknown</code>,</li>
-<li><code>product</code>,</li>
-<li><code>union</code>,</li>
-</ul></li>
-<li>an openness flag:
-<ul>
-<li><code>open</code>,</li>
-<li><code>closed</code>.</li>
-</ul></li>
-</ul>
-<p>For product and union nodes, outgoing edges are labeled by field
-names or tags. Edges are locally unique by label.</p>
-<p>Unlike the case of types, <strong>node identity in a pattern graph is
-semantic</strong>. If two edges point to the same pattern node, this
-means that the corresponding positions must be inhabited by the very
-same type.</p>
-<p>Therefore patterns are not quotiented by bisimulation in general.</p>
-<h2 id="filters-as-syntax">5. Filters As Syntax</h2>
-<p>A filter expression is a textual way of describing a pattern
-graph.</p>
-<p>Variables appearing in filters are not the semantic object itself.
-They are a device for serializing and reusing pattern graph nodes in
-syntax.</p>
-<p>For example, the two filters</p>
-<pre class="k"><code>{ (...) x, (...) y, ... }
-{ X x, X y, ... }</code></pre>
-<p>describe different pattern graphs:</p>
-<ul>
-<li>the first has two distinct target nodes for <code>x</code> and
-<code>y</code>,</li>
-<li>the second has one shared target node reached from both
-<code>x</code> and <code>y</code>.</li>
-</ul>
-<p>These two patterns are semantically different.</p>
-<h2 id="matching-a-type-against-a-pattern">6. Matching A Type Against A
-Pattern</h2>
-<p>Let <code>P</code> be a pattern graph and <code>T</code> a type
-graph. We say that <code>T</code> <strong>matches</strong>
-<code>P</code>, written</p>
-<pre class="text"><code>T ⊨ P,</code></pre>
-<p>if there exists a root-preserving graph morphism</p>
-<pre class="text"><code>h : nodes(P) → nodes(T)</code></pre>
-<p>such that:</p>
-<ol type="1">
-<li><p>if <code>p</code> is <code>unknown</code>, then <code>h(p)</code>
-may be any type node,</p></li>
-<li><p>if <code>p</code> is <code>product</code>, then <code>h(p)</code>
-is a product node,</p></li>
-<li><p>if <code>p</code> is <code>union</code>, then <code>h(p)</code>
-is a union node,</p></li>
-<li><p>if <code>p</code> is <code>closed</code>, then the outgoing
-labels of <code>h(p)</code> are exactly the outgoing labels of
-<code>p</code>,</p></li>
-<li><p>if <code>p</code> is <code>open</code>, then the outgoing labels
-of <code>h(p)</code> contain at least the outgoing labels of
-<code>p</code>,</p></li>
-<li><p>for every pattern edge</p>
-<pre class="text"><code>p --l--&gt; q</code></pre>
-<p>there is a corresponding type edge</p>
-<pre class="text"><code>h(p) --l--&gt; h(q).</code></pre></li>
-</ol>
-<p>Condition 6 is the crucial one: if two edges of <code>P</code> point
-to the same node <code>q</code>, then the corresponding edges of
-<code>T</code> must point to the same type node <code>h(q)</code>. This
-is how the graph structure of the pattern expresses “the same type”.</p>
-<p>We define:</p>
-<pre class="text"><code>Types(P) = { T : T ⊨ P }.</code></pre>
-<h3 id="proposition-0">Proposition 0</h3>
-<p>If <code>T ⊨ P</code>, then:</p>
-<ul>
-<li>the root kind of <code>T</code> is compatible with the root kind of
-<code>P</code>,</li>
-<li>every label explicitly present at the root of <code>P</code> is
-present at the root of <code>T</code>,</li>
-<li>if the root of <code>P</code> is closed, then <code>T</code> has no
-additional root labels.</li>
-</ul>
-<h4 id="proof">Proof</h4>
-<p>All three statements are immediate from the definition of the
-root-preserving morphism <code>h</code> and conditions 1-5 above,
-applied at the root node of <code>P</code>.</p>
-<h2 id="singleton-patterns-and-types">7. Singleton Patterns And
-Types</h2>
-<p>Every type graph <code>T</code> determines a closed pattern
-<code>Pat(T)</code> obtained by forgetting that it is a type and viewing
-it as a closed pattern graph.</p>
-<p>This gives the following proposition.</p>
-<h3 id="proposition-1">Proposition 1</h3>
-<p>For every type <code>T</code>, the pattern <code>Pat(T)</code> is
-singleton:</p>
-<pre class="text"><code>Types(Pat(T)) = { T }</code></pre>
-<p>up to the chosen notion of type equivalence.</p>
-<h4 id="proof-1">Proof</h4>
-<p>The identity map from <code>nodes(Pat(T))</code> to
-<code>nodes(T)</code> witnesses <code>T ⊨ Pat(T)</code>. Conversely,
-suppose <code>U ⊨ Pat(T)</code> via a root-preserving morphism
-<code>h</code>. Because every node of <code>Pat(T)</code> is either
-product or union, every node kind is preserved. Because every node is
-closed, the outgoing labels at each image node are exactly the outgoing
-labels of the corresponding node of <code>T</code>. Because every
-pattern edge must be respected by <code>h</code>, all target-sharing
-constraints are preserved as well. Therefore <code>h</code> is a graph
-isomorphism modulo the chosen equivalence on type graphs, and hence
-<code>U</code> is equivalent to <code>T</code>.</p>
-<h3 id="proposition-2">Proposition 2</h3>
-<p>Conversely, every singleton pattern determines a unique type up to
-type equivalence.</p>
-<h4 id="proof-2">Proof</h4>
-<p>Let <code>P</code> be singleton. By definition, <code>Types(P)</code>
-contains exactly one type up to equivalence. Choose any representative
-<code>T ∈ Types(P)</code>. Then <code>T</code> is the unique type
-determined by <code>P</code>, again up to the chosen equivalence
-relation.</p>
-<p>Thus types can be regarded as a special case of patterns.</p>
-<h2 id="polymorphic-values">8. Polymorphic Values</h2>
-<p>A <strong>polymorphic value</strong> is a pair</p>
-<pre class="text"><code>(P, v)</code></pre>
-<p>where:</p>
-<ul>
-<li><code>P</code> is a pattern graph,</li>
-<li><code>v</code> is a typed value <code>(T, t)</code>,</li>
-<li><code>T ⊨ P</code>.</li>
-</ul>
-<p>Equivalently:</p>
-<pre class="text"><code>PolyVal(P) = { (P, (T, t)) : T ⊨ P and t ∈ Tree(T) }.</code></pre>
-<p>So a pattern does not denote a set of raw trees. It denotes a set of
-typed values:</p>
-<pre class="text"><code>Val(P) = { (T, t) : T ⊨ P and t ∈ Tree(T) }.</code></pre>
-<p>This is a disjoint union over matching types, not an ordinary union
-of raw tree sets.</p>
-<h3 id="proposition-3">Proposition 3</h3>
-<p>For every type <code>T</code>,</p>
-<pre class="text"><code>Val(Pat(T)) = Val(T).</code></pre>
-<h4 id="proof-3">Proof</h4>
-<p>By Proposition 1, <code>Types(Pat(T)) = { T }</code> up to
-equivalence. Substituting this into the definition of
-<code>Val(P)</code> yields exactly the set of typed values whose type is
-<code>T</code>.</p>
-<h2 id="examples">9. Examples</h2>
-<h3 id="distinct-pattern-graphs">9.1. Distinct pattern graphs</h3>
-<p>Consider:</p>
-<pre class="k"><code>P1 = { (...) x, (...) y, ... }
-P2 = { X x, X y, ... }</code></pre>
-<p>Then <code>P1</code> and <code>P2</code> are different patterns.</p>
-<ul>
-<li><code>P1</code> allows the types at <code>x</code> and
-<code>y</code> to differ.</li>
-<li><code>P2</code> requires the types at <code>x</code> and
-<code>y</code> to be the same.</li>
-</ul>
-<p>Hence:</p>
-<pre class="text"><code>Types(P2) ⊊ Types(P1).</code></pre>
-<h4 id="proof-sketch">Proof sketch</h4>
-<p>Every type matching <code>P2</code> also matches <code>P1</code>,
-because identifying the target types of <code>x</code> and
-<code>y</code> is stronger than leaving them unrelated. The inclusion is
-strict because a product type with distinct types at <code>x</code> and
-<code>y</code> matches <code>P1</code> but not <code>P2</code>.</p>
-<h3 id="same-tree-different-typed-values">9.2. Same tree, different
-typed values</h3>
-<p>Let <code>t = {}|x</code>. Suppose <code>t</code> is accepted both
-by</p>
-<pre class="k"><code>T1 = &lt; {} x &gt;
-T2 = &lt; {} x, {} y &gt;</code></pre>
-<p>Then <code>(T1, t)</code> and <code>(T2, t)</code> are different
-typed values.</p>
-<p>The raw tree is the same, but the type is different.</p>
-<h3 id="proposition-4">Proposition 4</h3>
-<p>If <code>T ≠ U</code>, then:</p>
-<pre class="text"><code>Val(T) ∩ Val(U) = ∅.</code></pre>
-<h4 id="proof-4">Proof</h4>
-<p>An element of <code>Val(T)</code> has the form <code>(T, t)</code>.
-An element of <code>Val(U)</code> has the form <code>(U, u)</code>. If
-<code>(T, t) = (U, u)</code>, then necessarily <code>T = U</code>.
-Hence, when <code>T ≠ U</code>, the two sets are disjoint.</p>
-<h2 id="consequences-for-equality-and-compression">10. Consequences For
-Equality And Compression</h2>
-<p>Since values are intrinsically typed, raw tree equality is not
-sufficient for semantic equality.</p>
-<p>This has an immediate consequence for DAG compression. Suppose we
-have the raw tree</p>
-<pre class="k"><code>{{}|x a, {}|x b, {}|x c}</code></pre>
-<p>and consider two patterns:</p>
-<pre class="k"><code>P1 = { (...) a, (...) b, (...) c, ... }
-P2 = { X a, X b, X c, ... }</code></pre>
-<p>If only the raw tree is considered, the three occurrences of
-<code>{}|x</code> appear identical and a naive compressor may merge
-them. But semantically this is not always justified.</p>
-<ul>
-<li>Under <code>P1</code>, the three occurrences need not belong to the
-same type.</li>
-<li>Under <code>P2</code>, they must belong to the same type.</li>
-</ul>
-<p>Therefore canonical value sharing, when used as an optimization, must
-be relative to the typing information supplied by the pattern and the
-witness type. One must not collapse raw subtrees merely because they
-look the same as trees.</p>
-<h3 id="proposition-5">Proposition 5</h3>
-<p>There is, in general, no canonical DAG compression procedure that
-depends only on the raw value tree and is correct for all polymorphic
-values.</p>
-<h4 id="proof-5">Proof</h4>
-<p>Consider the raw tree</p>
-<pre class="text"><code>{{}|x a, {}|x b, {}|x c}.</code></pre>
-<p>As a raw tree, the three subtrees under <code>a</code>,
-<code>b</code>, and <code>c</code> are isomorphic. Hence any tree-only
-compressor cannot distinguish their occurrences by local tree structure
-alone. Now compare the two valid pattern contexts:</p>
-<pre class="text"><code>P1 = { (...) a, (...) b, (...) c, ... }
-P2 = { X a, X b, X c, ... }.</code></pre>
-<p>Under <code>P1</code>, the three occurrences are not forced to have
-the same type. Under <code>P2</code>, they are forced to have the same
-type because all three edges land in the same pattern node. So a
-compressor that always merges these subtrees is unsound for
-<code>P1</code>, while a compressor that never merges them fails to
-capture the canonical sharing justified by <code>P2</code>. Therefore no
-canonical sharing rule can be defined from the raw tree alone; typing
-information from the pattern and witness type is required.</p>
-<h3 id="proposition-6">Proposition 6</h3>
-<p>For a fixed polymorphic value <code>(P, (T, t))</code>, any canonical
-DAG compression of <code>t</code> must be invariant under equality of
-<strong>typed occurrences</strong>, not merely equality of raw
-subtrees.</p>
-<h4 id="proof-sketch-1">Proof sketch</h4>
-<p>By Proposition 4, typed values of different types are distinct even
-when represented by the same raw tree. Within a fixed witness type
-<code>T</code>, the pattern graph still matters because distinct
-positions of <code>P</code> may or may not be identified. Therefore the
-only semantically defensible sharing criterion is one that respects the
-typing/decorated occurrence information carried by <code>(P, T)</code>,
-not the undecorated tree <code>t</code> alone.</p>
-<h2 id="topological-remark">11. Topological Remark</h2>
-<p>There is a topology-like intuition behind patterns, but only for a
-fragment.</p>
-<p>If one looks only at open positive patterns, they behave like
-observable structural properties of types and suggest a topology or,
-more precisely, an Alexandrov-style structure on the class of types
-ordered by refinement.</p>
-<p>However, the full pattern formalism is richer than topology because
-it includes:</p>
-<ul>
-<li>closedness constraints,</li>
-<li>explicit graph sharing, which expresses sameness of type at
-different positions.</li>
-</ul>
-<p>These two features go beyond ordinary open-set semantics.</p>
-<h3 id="proposition-7">Proposition 7</h3>
-<p>The class of patterns is strictly richer than the open positive
-fragment.</p>
-<h4 id="proof-sketch-2">Proof sketch</h4>
-<p>The open positive fragment can describe only monotone structural
-requirements such as “at least these labels” and “these positions have
-these subpatterns”. It cannot express exact closedness, because
-closedness is not monotone under refinement. It also cannot express
-identification of two positions as “the same type” without preserving
-explicit graph sharing. Since full patterns include both closedness and
-shared-node identity, they strictly extend the open positive
-fragment.</p>
-<h2 id="summary">12. Summary</h2>
-<ul>
-<li>A type is a regular rooted graph denoting a set of accepted
-trees.</li>
-<li>A typed value is a pair <code>(T, t)</code> with
-<code>t ∈ Tree(T)</code>.</li>
-<li>A pattern is a rooted graph with node kind, openness, and semantic
-node identity.</li>
-<li>A filter is only syntax for serializing a pattern graph.</li>
-<li>A type matches a pattern via a root-preserving morphism respecting
-node kind, openness, labels, and shared targets.</li>
-<li>A pattern denotes a set of types, and therefore a set of typed
-values, not a set of raw trees.</li>
-<li>A polymorphic value is a pair <code>(P, (T, t))</code> with
-<code>T ⊨ P</code>.</li>
-<li>Types are exactly the singleton-pattern case.</li>
-<li>DAG compression of values is a representation optimization only and
-must respect typing information.</li>
-</ul>
-<h2 id="corollaries-for-binary-serialization">13. Corollaries For Binary
-Serialization</h2>
-<p>The previous propositions impose strong constraints on any correct
-binary format.</p>
-<h3 id="corollary-1">Corollary 1</h3>
-<p>The semantic payload of a serialized polymorphic value must
-determine:</p>
-<ul>
-<li>a pattern graph <code>P</code>,</li>
-<li>a witness typed value <code>(T, t)</code>,</li>
-</ul>
-<p>with <code>T ⊨ P</code>.</p>
-<p>It is not sufficient to serialize only a raw tree.</p>
-<h4 id="justification">Justification</h4>
-<p>By Proposition 4, type is part of value identity. By Proposition 5,
-the raw tree alone is insufficient to determine correct canonical
-sharing behavior.</p>
-<h3 id="corollary-2">Corollary 2</h3>
-<p>A closed monomorphic typed value is the special case where the
-serialized pattern is singleton.</p>
-<h4 id="justification-1">Justification</h4>
-<p>This is Proposition 1 together with Proposition 3.</p>
-<h3 id="corollary-3">Corollary 3</h3>
-<p>Any canonical DAG representation of the witness value must be
-computed from the decorated object <code>(P, T, t)</code>, not from
-<code>t</code> alone.</p>
-<h4 id="justification-2">Justification</h4>
-<p>This is exactly the content of Propositions 5 and 6.</p>
-<h3 id="corollary-4">Corollary 4</h3>
-<p>Pattern serialization must preserve explicit pattern-node
-identity.</p>
-<h4 id="justification-3">Justification</h4>
-<p>Pattern node sharing expresses sameness of type at different
-positions. Replacing a pattern graph by any representation that forgets
-this identity changes its denotation.</p>
-<h3 id="corollary-5">Corollary 5</h3>
-<p>For singleton patterns, one may replace the explicit serialized
-pattern graph by a canonical type reference as a compact optimization,
-provided that the decoding semantics is unchanged.</p>
-<h4 id="justification-4">Justification</h4>
-<p>By Proposition 2, a singleton pattern determines a unique type up to
-equivalence. Therefore the explicit graph may be recoverable from a
-canonical type identifier.</p>

package/DOCS/dependency-graph.html

@@ -1,140 +0,0 @@
-<h1 id="project-dependency-graph">Project Dependency Graph</h1>
-<p><em>Auto-generated by scripts/generate-dependency-graph.mjs.</em></p>
-<pre class="mermaid"><code>graph TD
-    classDef default fill:#fff,stroke:#333,stroke-width:2px,color:#000;
-
-    Graph_mjs[&quot;Graph.mjs (1.9 KB)&lt;br/&gt;██&quot;]
-    TypeGraph_mjs[&quot;TypeGraph.mjs (1.1 KB)&lt;br/&gt;█&quot;]
-    TypePatternGraph_mjs[&quot;TypePatternGraph.mjs (8.0 KB)&lt;br/&gt;████████&quot;]
-    Value_mjs[&quot;Value.mjs (5.4 KB)&lt;br/&gt;█████&quot;]
-    augmentation_mjs[&quot;augmentation.mjs (6.9 KB)&lt;br/&gt;███████&quot;]
-    codecs_example_pipeline_mjs[&quot;codecs/example-pipeline.mjs (5.1 KB)&lt;br/&gt;█████&quot;]
-    codecs_ieee_mjs[&quot;codecs/ieee.mjs (4.3 KB)&lt;br/&gt;████&quot;]
-    codecs_int_mjs[&quot;codecs/int.mjs (3.5 KB)&lt;br/&gt;████&quot;]
-    codecs_json_codec_mjs[&quot;codecs/json-codec.mjs (6.2 KB)&lt;br/&gt;██████&quot;]
-    codecs_json_mjs[&quot;codecs/json.mjs (1.5 KB)&lt;br/&gt;██&quot;]
-    codecs_k_parse_mjs[&quot;codecs/k-parse.mjs (3.0 KB)&lt;br/&gt;███&quot;]
-    codecs_k_print_mjs[&quot;codecs/k-print.mjs (1.5 KB)&lt;br/&gt;██&quot;]
-    codecs_runtime_codec_mjs[&quot;codecs/runtime/codec.mjs (25.7 KB)&lt;br/&gt;████████████████████&quot;]
-    codecs_runtime_ieee_pattern_mjs[&quot;codecs/runtime/ieee-pattern.mjs (1.1 KB)&lt;br/&gt;█&quot;]
-    codecs_runtime_pattern_json_mjs[&quot;codecs/runtime/pattern-json.mjs (3.5 KB)&lt;br/&gt;███&quot;]
-    codecs_runtime_prefix_codec_mjs[&quot;codecs/runtime/prefix-codec.mjs (13.7 KB)&lt;br/&gt;██████████████&quot;]
-    codecs_runtime_show_value_mjs[&quot;codecs/runtime/show-value.mjs (2.1 KB)&lt;br/&gt;██&quot;]
-    codecs_runtime_test_codec_mjs[&quot;codecs/runtime/test-codec.mjs (3.0 KB)&lt;br/&gt;███&quot;]
-    codecs_runtime_typeFromValue_mjs[&quot;codecs/runtime/typeFromValue.mjs (0.9 KB)&lt;br/&gt;█&quot;]
-    codecs_runtime_unicode_string_mjs[&quot;codecs/runtime/unicode-string.mjs (7.5 KB)&lt;br/&gt;████████&quot;]
-    codecs_show_mjs[&quot;codecs/show.mjs (1.5 KB)&lt;br/&gt;██&quot;]
-    codecs_string_codec_mjs[&quot;codecs/string-codec.mjs (4.5 KB)&lt;br/&gt;█████&quot;]
-    codecs_unit_mjs[&quot;codecs/unit.mjs (1.6 KB)&lt;br/&gt;██&quot;]
-    codecs_utf16_mjs[&quot;codecs/utf16.mjs (2.2 KB)&lt;br/&gt;██&quot;]
-    codecs_utf8_mjs[&quot;codecs/utf8.mjs (1.3 KB)&lt;br/&gt;█&quot;]
-    codes_mjs[&quot;codes.mjs (9.9 KB)&lt;br/&gt;██████████&quot;]
-    compiler_mjs[&quot;compiler.mjs (3.9 KB)&lt;br/&gt;████&quot;]
-    convergence_mjs[&quot;convergence.mjs (6.5 KB)&lt;br/&gt;██████&quot;]
-    export_mjs[&quot;export.mjs (5.2 KB)&lt;br/&gt;█████&quot;]
-    hash_mjs[&quot;hash.mjs (1.1 KB)&lt;br/&gt;█&quot;]
-    index_mjs[&quot;index.mjs (1.9 KB)&lt;br/&gt;██&quot;]
-    k_mjs[&quot;k.mjs (2.7 KB)&lt;br/&gt;███&quot;]
-    object_mjs[&quot;object.mjs (26.3 KB)&lt;br/&gt;████████████████████&quot;]
-    pretty_mjs[&quot;pretty.mjs (5.6 KB)&lt;br/&gt;██████&quot;]
-    repl_mjs[&quot;repl.mjs (29.3 KB)&lt;br/&gt;████████████████████&quot;]
-    run_mjs[&quot;run.mjs (14.4 KB)&lt;br/&gt;██████████████&quot;]
-    symbol_table_mjs[&quot;symbol-table.mjs (2.7 KB)&lt;br/&gt;███&quot;]
-    typing_mjs[&quot;typing.mjs (4.9 KB)&lt;br/&gt;█████&quot;]
-    unification_mjs[&quot;unification.mjs (5.4 KB)&lt;br/&gt;█████&quot;]
-    valueIO_mjs[&quot;valueIO.mjs (1.8 KB)&lt;br/&gt;██&quot;]
-
-    TypePatternGraph_mjs --&gt; Graph_mjs
-    TypePatternGraph_mjs --&gt; unification_mjs
-    TypePatternGraph_mjs --&gt; TypeGraph_mjs
-    augmentation_mjs --&gt; codes_mjs
-    codecs_example_pipeline_mjs --&gt; codecs_runtime_codec_mjs
-    codecs_example_pipeline_mjs --&gt; codecs_runtime_prefix_codec_mjs
-    codecs_example_pipeline_mjs --&gt; codecs_runtime_pattern_json_mjs
-    codecs_example_pipeline_mjs --&gt; Value_mjs
-    codecs_example_pipeline_mjs --&gt; hash_mjs
-    codecs_ieee_mjs --&gt; Value_mjs
-    codecs_ieee_mjs --&gt; codecs_runtime_prefix_codec_mjs
-    codecs_ieee_mjs --&gt; codecs_runtime_ieee_pattern_mjs
-    codecs_int_mjs --&gt; Value_mjs
-    codecs_int_mjs --&gt; codecs_runtime_prefix_codec_mjs
-    codecs_json_codec_mjs --&gt; Value_mjs
-    codecs_json_codec_mjs --&gt; codecs_string_codec_mjs
-    codecs_json_codec_mjs --&gt; codecs_runtime_ieee_pattern_mjs
-    codecs_json_mjs --&gt; codecs_runtime_prefix_codec_mjs
-    codecs_json_mjs --&gt; codecs_json_codec_mjs
-    codecs_k_parse_mjs --&gt; index_mjs
-    codecs_k_parse_mjs --&gt; valueIO_mjs
-    codecs_k_parse_mjs --&gt; codecs_runtime_codec_mjs
-    codecs_k_parse_mjs --&gt; codecs_runtime_pattern_json_mjs
-    codecs_k_parse_mjs --&gt; codecs_runtime_prefix_codec_mjs
-    codecs_k_print_mjs --&gt; codecs_runtime_prefix_codec_mjs
-    codecs_runtime_codec_mjs --&gt; Value_mjs
-    codecs_runtime_codec_mjs --&gt; TypePatternGraph_mjs
-    codecs_runtime_codec_mjs --&gt; typing_mjs
-    codecs_runtime_codec_mjs --&gt; codes_mjs
-    codecs_runtime_codec_mjs --&gt; codecs_runtime_pattern_json_mjs
-    codecs_runtime_ieee_pattern_mjs --&gt; codes_mjs
-    codecs_runtime_ieee_pattern_mjs --&gt; codecs_runtime_codec_mjs
-    codecs_runtime_ieee_pattern_mjs --&gt; codecs_runtime_pattern_json_mjs
-    codecs_runtime_prefix_codec_mjs --&gt; Value_mjs
-    codecs_runtime_prefix_codec_mjs --&gt; codecs_runtime_codec_mjs
-    codecs_runtime_prefix_codec_mjs --&gt; codecs_runtime_pattern_json_mjs
-    codecs_runtime_prefix_codec_mjs --&gt; codecs_runtime_unicode_string_mjs
-    codecs_runtime_show_value_mjs --&gt; Value_mjs
-    codecs_runtime_test_codec_mjs --&gt; codecs_runtime_codec_mjs
-    codecs_runtime_test_codec_mjs --&gt; codecs_runtime_prefix_codec_mjs
-    codecs_runtime_test_codec_mjs --&gt; codecs_runtime_pattern_json_mjs
-    codecs_runtime_test_codec_mjs --&gt; Value_mjs
-    codecs_runtime_test_codec_mjs --&gt; hash_mjs
-    codecs_runtime_typeFromValue_mjs --&gt; Value_mjs
-    codecs_runtime_unicode_string_mjs --&gt; Value_mjs
-    codecs_show_mjs --&gt; codecs_runtime_prefix_codec_mjs
-    codecs_show_mjs --&gt; codecs_runtime_show_value_mjs
-    codecs_string_codec_mjs --&gt; codecs_runtime_codec_mjs
-    codecs_string_codec_mjs --&gt; codecs_runtime_prefix_codec_mjs
-    codecs_string_codec_mjs --&gt; codecs_runtime_pattern_json_mjs
-    codecs_string_codec_mjs --&gt; codecs_runtime_unicode_string_mjs
-    codecs_unit_mjs --&gt; Value_mjs
-    codecs_unit_mjs --&gt; codecs_runtime_prefix_codec_mjs
-    codecs_utf16_mjs --&gt; codecs_string_codec_mjs
-    codecs_utf8_mjs --&gt; codecs_string_codec_mjs
-    codes_mjs --&gt; hash_mjs
-    compiler_mjs --&gt; hash_mjs
-    compiler_mjs --&gt; TypePatternGraph_mjs
-    compiler_mjs --&gt; Graph_mjs
-    compiler_mjs --&gt; codes_mjs
-    compiler_mjs --&gt; augmentation_mjs
-    compiler_mjs --&gt; export_mjs
-    compiler_mjs --&gt; convergence_mjs
-    convergence_mjs --&gt; pretty_mjs
-    convergence_mjs --&gt; typing_mjs
-    export_mjs --&gt; hash_mjs
-    export_mjs --&gt; pretty_mjs
-    index_mjs --&gt; Value_mjs
-    index_mjs --&gt; valueIO_mjs
-    index_mjs --&gt; compiler_mjs
-    index_mjs --&gt; run_mjs
-    index_mjs --&gt; codes_mjs
-    k_mjs --&gt; index_mjs
-    k_mjs --&gt; codecs_runtime_prefix_codec_mjs
-    k_mjs --&gt; object_mjs
-    object_mjs --&gt; index_mjs
-    object_mjs --&gt; run_mjs
-    object_mjs --&gt; codes_mjs
-    object_mjs --&gt; TypePatternGraph_mjs
-    object_mjs --&gt; pretty_mjs
-    pretty_mjs --&gt; TypePatternGraph_mjs
-    repl_mjs --&gt; index_mjs
-    repl_mjs --&gt; run_mjs
-    repl_mjs --&gt; codes_mjs
-    repl_mjs --&gt; Value_mjs
-    repl_mjs --&gt; pretty_mjs
-    repl_mjs --&gt; object_mjs
-    repl_mjs --&gt; codecs_runtime_show_value_mjs
-    run_mjs --&gt; Value_mjs
-    run_mjs --&gt; codecs_runtime_codec_mjs
-    run_mjs --&gt; codecs_runtime_pattern_json_mjs
-    symbol_table_mjs --&gt; hash_mjs
-    typing_mjs --&gt; TypePatternGraph_mjs
-    valueIO_mjs --&gt; Value_mjs</code></pre>