@fraczak/k 6.1.1 → 6.1.3

package/Code-derivation-tests/pattern-envelope.mjs

@@ -44,6 +44,32 @@ assert.deepEqual(decodedMerged.pattern, INT_PATTERN);
 const identityResult = k.compile("()")(withPattern(two, INT_PATTERN));
 assert.deepEqual(identityResult.pattern, INT_PATTERN);
 
+const wrappedFloatPattern = [
+  ["closed-product", [["result", 1], ["flags", 6]]],
+  ["closed-product", [["sign", 2], ["exponent", 3], ["fraction", 4]]],
+  ["closed-union", [["+", 5], ["-", 5]]],
+  ["closed-product", [["0", 2]]],
+  ["closed-product", [["0", 2]]],
+  ["closed-product", []],
+  ["closed-union", [["inexact", 5]]]
+];
+const wrappedFloat = new Product({
+  result: new Product({
+    sign: new Variant("+", new Product({})),
+    exponent: new Product({ 0: new Variant("1", new Product({})) }),
+    fraction: new Product({ 0: new Variant("0", new Product({})) })
+  }),
+  flags: new Variant("inexact", new Product({}))
+});
+const resultProjection = k.compile(".result")(withPattern(wrappedFloat, wrappedFloatPattern));
+assert.deepEqual(resultProjection.pattern, [
+  ["closed-product", [["sign", 1], ["exponent", 3], ["fraction", 4]]],
+  ["closed-union", [["+", 2], ["-", 2]]],
+  ["closed-product", []],
+  ["closed-product", [["0", 1]]],
+  ["closed-product", [["0", 1]]]
+]);
+
 assert.throws(
   () => k.compile(".x")(withPattern(two, INT_PATTERN)),
   /Type Error in 'comp'.*Value envelope does not intersect expression input pattern/s

package/DOCS/BIG_PICTURE.md

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

package/DOCS/DIVERGENCE_DETECTION.md

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

package/DOCS/REPL.md

@@ -45,6 +45,9 @@ complete.
 | `:C name` | Show canonical code definition |
 | `:codes` | List type aliases |
 | `:rels` | List relation aliases |
+| `:codec load file` | Load an importable REPL codec module |
+| `:codec list` | List loaded REPL codecs |
+| `:input type [codec]` | Read the next line as codec input for a singleton type |
 | `:load [--no-alias] file` | Load `.k` source or `.klib` into the current state |
 | `:klib file` | Export current state as a `.klib` library |
 | `:ko file expr` | Export a `.ko` executable with `expr` as main |
@@ -133,6 +136,10 @@ Tab completion covers:
 
 Type aliases also complete in `$name` position inside raw k input.
 
+For codec commands, completion covers `:codec load`, `:codec list`, file paths
+after `:codec load`, singleton type names after `:input`, and loaded codec names
+after the input type.
+
 ## Loading
 
 ### `:load [--no-alias] file.k`
@@ -147,6 +154,32 @@ Reads the plain-JSON library file and merges its codes, relations, aliases, and
 metadata into the session. Aliases are recovered from `meta[hash].origins[]`
 unless `--no-alias` is used.
 
+## Codecs
+
+REPL codecs are keyed by canonical singleton code hashes. Open filters are not
+used for codec dispatch.
+
+### `:codec load file`
+
+Loads an importable ES module that exports a codec shape:
+
+```js
+export const name = "utf8";
+export const codes = ["@..."];
+export function parse(text) { /* text -> Value */ }
+export function print(value) { /* Value -> text */ }
+```
+
+A codec may export `patterns` instead of `codes`; each pattern must be a
+singleton closed property-list pattern, and its code hash is recalculated by the
+REPL.
+
+### `:input type [codec]`
+
+Resolves `type` to a canonical singleton code, selects the registered codec,
+and consumes the next line verbatim as codec input. The parsed value is validated
+against that code before becoming the current value.
+
 ## Export
 
 ### `:klib file`

package/DOCS/TYPE_DERIVATION.md

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

package/DOCS/a.html

@@ -0,0 +1,398 @@
+<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>