@fraczak/k 2.1.6 → 3.0.2

package/BIG_PICTURE.md

@@ -0,0 +1,211 @@
+
+`Kernel-code` is an experiment aiming to define a "perfect programming language".
+
+## Basics
+
+The language describes "partial first-order functions" on "printable" values.
+The printable values can be seen as rooted, edge-labeled trees, intuitively similar to an
+XML or a JSON document. The values are always typed.
+
+### Types (codes)
+
+Formally, a _type_ is a (subclass of) finite tree automata. The type defines a set of its 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.
+
+The set of all types can be seen as the universal deterministic (infinite) tree automaton.
+Every node of that automaton defines a type; only a finite set of nodes are reachable from
+any node.
+
+Types are defined by two constructs:
+
+1. Product
+2. Union (also called tagged or disjoint union)
+
+Given a set (possibly empty) of types `t1, t2, ..., tn` and a set of pairwise different tags (labels) `l1, l2, ..., ln`,
+
+- by `{ t1 l1, t2 l2, ..., tn ln }`, we define a _product type_ with exactly `n` projection functions `.l1`, `.l2`, `...`, `.ln`,
+  mapping 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`,
+  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
+for a given value of the union type.
+
+Some properties of these types:
+
+1. Singleton product and singleton union types, `{ t label }` and `< t label >`, are equivalent as they have
+   the same set of values (and the same projection function `.label`). That's why, we not allow singleton product nor
+   singleton union types in the syntax of the language. The other benefit is that we will be able to use the same systax
+   for values of both product and union types, interpretting every singleton product-like value, e.g., `{ a_value label }`,
+   as a union type value (a variant).  
+2. The empty product type `{}` has a single value, called the _unit_ and also denoted by `{}`, which has no fields.
+3. The empty union type `<>` has no values.
+4. The product and union types form dual categories.
+
+### Partial functions
+
+A _partial function_ is a function that is not defined for every value of its domain.
+
+There are three ways of combining partial functions:
+
+1. __Composition__: we write a composition of `f` and `g` as `(f  g)`, meaning that if `f` is defined on valye `x` producing `y`,
+   and `g` is defined on value `y` producing `z`, then `(f g)` is defined on value `x` producing `z`.
+2. __Union__: we write `< f1, f2 >` for a union of two functions `f1` and `f2`, meaning that
+   if `f1` is defined on value `x` producing `y`, then `< f1, f2 >`
+   is defined on value `x` producing `y`. Otherwise, i.e., when `f1` is not defined for `x`, `< f1 f2 >` acts as `f2`.
+3. __Product__: we write `{f1 lab1, f2 lab2 }` for a product of two functions `f1` and `f2`, meaning that if `f1` and `f2`
+   are both defined on value `x` producing `y1` and `y2`, respectively, then `{f1 lab1, f2 lab2 }`
+   is defined on value `x` producing `{y1 lab1, y2 lab2}`. Otherwise, `{f1 lab1, f2 lab2 }` is not defined for `x`.
+
+Actually, all of the above operations take any number of arguments, not only two. For example,
+empty composition, `()`, defines the identity function.
+
+### Program
+
+A `kernel-core` program is a set of definitions of types and partial functions followed by an _expression_,
+which is the partial function the program defines.
+
+The language syntax is defined by:
+
+```bnf
+program ::= (type_definition | function_definition) * expression
+
+type_definition ::= '$' type_name '=' type ';'
+type ::= '{' type_label_list '}' | '<' type_label_list '>'
+type_label_list ::= /* empty */ | ( type_expression label_name ',' ) + type_expression label_name
+type_expression ::= type_name | type
+
+function_definition ::= function_name '=' expression ';'
+expression ::= projection | typing | composition | union | product | function_name
+projection ::= '.' label_name
+typing ::= '$' tape_expression 
+composition ::= '(' expression * ')'  
+union ::= '<' (expression ',') + expression '>' 
+product ::= '{' expression_label_list '}'
+expression_label_list ::= /* empty */ | ( expression label_name ',' ) * expression label
+```
+
+We assume that the `type_name`, `function_name`, and `label_name` are identifiers (strings) such that:
+
+1. All defined type names are distinct.
+2. All defined function names are distinct.
+3. All label names within a type definition or a `product` expression are locally distinct.
+
+The `typing` expression acts as a type annotation and can be seen as a 'filter', i.e., an identity
+function defined only for the values of the corresponding type.
+
+That's it.
+No `int`, no `if` statement, no `loop`, no `throw`, no _closure_, no _annotations_, and no macros.
+Just types and partial functions.
+
+### Normalization
+
+All type names are replaced by the hash of their canonical representation.
+
+We will also replace the function name by the hash of the normalized unfolded definition of the function.
+Obviously, two different definitions of the same function may have different hashes.
+
+This approach solves the problem of modules and imports and opens the door to a universal
+registry of types (schemas) and functions.
+
+## Typing and Polymorphism (codes and filters/patterns)
+
+Abstract Syntax Tree of a program after parsing 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 canonicals representations for types and normalized
+representations for functions, so they could be effectively reused.
+
+The normalization steps are:
+
+1. Build the _type graph_ from all types used by the program, i.e., used in _type definitions_ 
+   as well as type expressions used in _function definitions_ and the _main expression_.
+2. Annotate the expressions with types or type patterns; every node of the AST is annotated with a pair of type patterns.
+3. Turn the _singleton_ type patterns into types and add them to the _type graph_. Go to (2) unless no change.
+4. Normalize the function definitions by rewriting them as the fix-point of a single equation.
+
+### Example
+
+```k
+$ bit = < {} o, {} i >;
+bit0 = {{} o} $bit;
+bit1 = {{} i} $bit;
+
+$ byte = { bit b0, bit b1, bit b2, bit b3 };
+zero = bit0 { () b0, () b1, () b2, () b3 } $byte;
+
+inc = $byte
+   <
+      { .b0.o bit0  overflown,  {bit1 b0, .b1  b1,  .b2 b2,  .b3 b3 } byte }, 
+      { .b1.o bit0  overflown,  {bit0 b0, bit1 b1,  .b2 b2,  .b3 b3 } byte },
+      { .b2.o bit0  overflown,  {bit0 b0, bit0 b1, bit1 b2,  .b3 b3 } byte },
+      { .b3.o bit0  overflown,  {bit0 b0, bit0 b1, bit0 b2, bit1 b3 } byte },
+      { bit1        overflown,  zero                                  byte }
+   >  
+;
+
+-- inc with overflown flag (polymorphism)
+inc_o = 
+  { .byte inc inc, .overflown overflown }  
+  {
+    .inc.byte                             byte, 
+     <.overflown.i bit1, .inc.overflown > overflown
+  }
+;
+
+inc3 = inc inc_o inc_o;
+
+inc3
+```
+
+In the above program, we define a type `bit` a union of two unit types, 
+and a type `byte` as a product, for simplicity, of four `bit`s. 
+
+Functions `bit0`, `bit1`, and `zero` are "constant polymorphic functions", meaning:
+
+- constant: if defined, they always return exactly the same value;
+- polymorphic: they are defined for more than one pair of input and output type: functions
+  `bit1` and `bit2` are of type `X -> bit`, and `zero` is of type `X -> byte`, where `X`
+  denotes an unconstrained type pattern.
+
+Functions `inc` and `inc3` are (non-polymorphic) functions of types
+`byte -> { bit overflown, byte byte }` and
+`{ bit overflown, byte byte } -> { bit overflown, byte byte }`, respectively.
+
+Function `inc_o` is a polymorphic function of type patterns: `X -> Y` with
+following constraints:
+
+- `X` is a product type with at least two fields: `byte` and `overflown`, denoted by:
+   > `?{ byte byte, Z overflown, ...}`;
+- `Z` is a type (union or product) with field `i` denoted by:
+   > `?( V i, ...)`;
+- `V` is unconstrained;
+- `Y` is a product type with exactly two fields: `byte` and `overflown`, denoted by:
+   > `?{ byte byte, bit overflown }`;
+
+The type pattern for `Y` is _singleton_, as only one type fits the pattern,
+whereas the other type patterns are not.
+
+In this example, we were able to find the most general type pattern for all sub-expressions of the program. However, we still do not have a way to find the most general type patterns in the general case. This is work in progress.
+
+## Universal Schema Registry
+
+Since the normalization process for types is fast and deterministic, we can build a universal schema registry that will store all invented types. The registry will be a key-value store, where the key is the hash of the normalized type, 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.
+
+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, e.g., for autocomplition. Searching for polymorphic functions is more complicated, as we need to find the function whose input and output type patterns fit given types.
+
+
+## Serialization and Compilation
+
+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 be compiled into deterministic finite (pushdown) transducers.
+
+## Linking with Other Languages
+
+## Streams and Arrays (Map-Reduce)

package/Code-derivation-tests/bnat.mjs

@@ -0,0 +1,10 @@
+import { t, in_out } from './index.mjs';
+import fs from 'node:fs';
+import assert from 'assert';
+
+t(fs.readFileSync("./Examples/bnat-patterns.k").toString("utf8"), (annotated) => {
+    const {input,output} = in_out(annotated);
+    assert.equal(output.code, annotated.representatives["bnat"]);
+    assert.equal(input.code, annotated.representatives["pair"]);
+    console.log("OK");
+});

package/Code-derivation-tests/built-in.mjs

@@ -0,0 +1,19 @@
+import { t, in_out } from './index.mjs';
+import assert from 'assert';
+
+function is_result_code(code) {
+    return function(annotated) {
+        const {output} = in_out(annotated);
+        assert.strictEqual(output.code, code);
+        console.log('OK');
+    }
+}
+
+t('true', is_result_code('bool'));
+t('false $bool', is_result_code('bool'));
+t('1', is_result_code('int'));
+t('12 $int', is_result_code('int'));
+t('"ala"', is_result_code('string'));
+t('"a" $string', is_result_code('string'));
+
+t('${} true $bool 1 $int "a" $string', is_result_code('string'));

package/Code-derivation-tests/dot.mjs

@@ -0,0 +1,15 @@
+import { t, in_out } from './index.mjs';
+import assert from 'assert';
+
+t(`
+$b = < {} true, {} false > ; 
+$pair = { b one, b two } ;
+
+$b {1 one, () two, () c} .one
+
+`, (annotated) => {
+    const {input,output} = in_out(annotated);
+    assert.equal(input.code, annotated.representatives["b"]);
+    assert.equal(output.code, "int");
+    console.log("OK");
+});

package/Code-derivation-tests/index.mjs

@@ -0,0 +1,20 @@
+import { annotate } from "../index.mjs";
+
+function in_out(annotated) {
+  const [input,output] = annotated.rels.__main__[0].patterns.map( (pat) => 
+    annotated.patternNodes[pat]
+  );
+  return { input, output };
+}
+
+
+function t(script, cb = (annotated) => console.log(in_out(annotated))) {
+  // console.log("--- Testing Code Derivation ---");
+  const annotated = annotate(script);
+  // console.log(JSON.stringify(annotated, "", 2));
+  return cb(annotated); 
+}
+
+export default { t, in_out };
+export { t, in_out };
+

package/Code-derivation-tests/loop.mjs

@@ -0,0 +1,11 @@
+import { t, in_out } from './index.mjs';
+import assert from 'assert';
+
+t(` < .a, () > `, (annotated) => {
+    const {input,output} = in_out(annotated);
+    assert.equal(input.type, "union");
+    assert.equal(output, input); 
+    console.log("OK");
+}); 
+
+// Notice that the following are equivalent: '<(), .a>', '<()>', and '()';

package/Code-derivation-tests/nat.mjs

@@ -0,0 +1,10 @@
+import { t, in_out } from './index.mjs';
+import fs from 'node:fs';
+import assert from 'assert';
+
+t(fs.readFileSync("./Examples/nat.k").toString("utf8"), (annotated) => {
+    const {input,output} = in_out(annotated);
+    assert.equal(output.code, annotated.representatives["nat"]);
+    assert.equal(input.code, annotated.representatives["nat"]);
+    console.log("OK");
+});

package/Code-derivation-tests/not-not.mjs

@@ -0,0 +1,14 @@
+import { t, in_out } from './index.mjs';
+import assert from 'assert';
+
+t(`$b = < {} true, {} false > ;
+   true = {{} true} $b;
+   false = {{} false} $b; 
+   not = $b < .true false, .false true >;
+   not not
+`, (annotated) => {
+   const {input,output} = in_out(annotated);
+   assert.equal(input.code, annotated.representatives["b"]);
+   assert.equal(output.code, annotated.representatives["b"]);
+   console.log("OK");
+   });

package/Code-derivation-tests/product.mjs

@@ -0,0 +1,21 @@
+import { t, in_out } from './index.mjs';
+import assert from 'assert';
+
+t('{}', (annotated) => {
+  const {input,output} = in_out(annotated);
+  assert.equal(input.type, null);
+  assert.equal(output.code, annotated.representatives["{}"]);
+  console.log("OK");
+});
+
+t(`
+  $b = < {} true, {} false > ; 
+  $pair = { b one, b two } ;
+
+   {() one, () two} $pair
+`, (annotated) => {
+  const {input,output} = in_out(annotated);
+  assert.equal(input.code, annotated.representatives["b"]);
+  assert.equal(output.code, annotated.representatives["pair"]);
+  console.log("OK");
+});

package/Code-derivation-tests/rlz.mjs

@@ -0,0 +1,14 @@
+import { t, in_out } from './index.mjs';
+import assert from 'assert';
+
+t(`
+ $nat = < {} _, nat 0, nat 1>;
+ zero = {{{} _} 0} $nat;
+ rlz =  <.0._ zero, .0 rlz, ()>;
+ rlz
+ `, (annotated) => {
+    const {input,output} = in_out(annotated);
+    assert.equal(output.code, annotated.representatives["nat"]);
+    assert.equal(input.code, annotated.representatives["nat"]);
+    console.log("OK");
+ });

package/Code-derivation-tests/vector.mjs

@@ -0,0 +1,28 @@
+import { t, in_out } from './index.mjs';
+import assert from 'assert';
+
+t('[]', (annotated) => {
+  const {input,output} = in_out(annotated);
+  assert.equal(input.type, null);
+  assert.equal(output.type, "vector");
+  console.log("OK");
+});
+
+t(`$int [ $int true, false ]`, (annotated) => {
+  const {input,output} = in_out(annotated);
+  assert.equal(input.code, "int");
+  assert.equal(output.type, "vector");
+  console.log("OK");
+});
+
+t(`$int [ $int true, false ] .0`,  (annotated) => {
+  const {input,output} = in_out(annotated);
+  assert.equal(input.code, "int");
+  assert.equal(output.code, "bool");
+  console.log("OK");
+});
+
+// assert.throws(() => t(`$int [ $int true, 12 ]`), /Error/);
+// console.log("OK");
+
+// t(`[]`);

package/INTRO.md

@@ -0,0 +1,88 @@
+### Introduction to Kernel/Core
+
+**Kernel/Core** is a minimal, gradually typed, first-order functional programming language designed for defining and transforming data using partial functions. It is built on the foundation of Algebraic Data Types (ADTs), specifically tagged unions and products.
+
+#### Core Concepts
+
+1. **Statements**:
+   - The program consists of a possibly empty list of statements, each ending with a semicolon (`;`), followed by an expression.
+   - There are two types of statements:
+     - **Code Definitions**: Define data types and start with a dollar sign (`$`).
+     - **Relation Definitions**: Define partial functions (transformations) of data.
+
+2. **Codes**:
+   - Codes represent data types and can be either unions (`<...>`) or products (`{...}`).
+   - Example: 
+     ```kernelcore
+     $ bool = <{} true, {} false>;
+     $ pair_of_bools = {bool x, bool y};
+     ```
+
+3. **Relations**:
+   - Relations are partial functions defined to transform data from one type to another.
+   - Example:
+     ```kernelcore
+     is_x_true = $pair_of_bools (.x .true);
+     ```
+
+4. **Composition of Partial Functions**:
+   - **Sequential (Functional) Composition**: Sequential application of partial functions.
+     ```kernelcore
+     (.x .true)
+     ```
+   - **Parallel (Product) Composition**: Combine multiple partial functions to construct a new product type.
+     ```kernelcore
+     {.x x_value, .y y_value}
+     ```
+   - **Concurrent (Union) Composition**: Try different functions in sequence, returning the first successful result.
+     ```kernelcore
+     <{.x .true false_bool}, {} true_bool>
+     ```
+
+5. **Constants**:
+   - Constants are defined as partial functions that ignore their input.
+   - Example:
+     ```kernelcore
+     true_bool = {{} true} $bool;
+     false_bool = {{} false} $bool;
+     ```
+
+#### Example Program
+
+```kernelcore
+// Define a boolean type as a union of true and false
+$ bool = <{} true, {} false>;
+
+// Define a pair of booleans as a product of two booleans
+$ pair_of_bools = {bool x, bool y};
+
+// Check if the `x` field is `true`
+is_x_true = $pair_of_bools (.x .true);
+
+// Extract both `x` and `y` fields into a new product
+extract_both = $pair_of_bools {.x x_value, .y y_value} $pair_of_bools;
+
+// Check if either `x` or `y` is `true`
+is_any_true = $pair_of_bools <{.x .true false_bool}, {} true_bool> $bool;
+
+// Define constants
+true_bool = {{} true} $bool;
+false_bool = {{} false} $bool;
+
+// Create instances of `pair_of_bools`
+pair1 = {true_bool x, true_bool y} $pair_of_bools;
+pair2 = {true_bool x, false_bool y} $pair_of_bools;
+pair3 = {false_bool x, false_bool y} $pair_of_bools;
+
+// Example usage of the functions
+result1 = pair1 is_x_true;       // Should return true
+result2 = pair2 is_x_true;       // Should return true
+
+both_values = pair1 extract_both; // Should return {x_value true, y_value true}
+
+any_true1 = pair1 is_any_true;   // Should return true
+any_true2 = pair2 is_any_true;   // Should return true
+any_true3 = pair3 is_any_true;   // Should return false
+```
+
+This brief introduction covers the fundamental concepts of Kernel/Core, enabling you to start defining data types and writing partial functions to transform data.

package/README.md

@@ -76,9 +76,10 @@ There are three ways of combining functions:
 ### Syntactic sugar
 
 - parenthesis can be omitted, except for the empty composition `()`,
-- dot (`.`) in "projection" acts as a separator so the space around it can be omitted.
+- dot (`.`) in "projection" acts as a separator so the space around it
+  can be omitted.
 
-For example, `[(.toto .titi (.0 .1))]` can be written as `[.toto.titi.0.1]`.
+For example, `(.toto .titi (.0 .1))` can be written as `.toto.titi.0.1`.
 
 Comments can be introduced by `//`, `--`, `%`, or `#` and extends to
 the end of line.  Multiline `C`-like comments, `/* ... */`, are also
@@ -118,8 +119,9 @@ projection to the canonicat string representation of the value, e.g.:
 #### Vector product
 
 Vector product can be seen as an abbreviation for product whose field
-names are integers starting from zero. E.g., `{.toto 0, .titi 1, 123 2}`
-can be written as `[.toto, .titi, 123]`.
+names are integers starting from zero.  
+E.g., `{.toto 0, .titi 1, 123 2}` can be written as  
+`[.toto, .titi, 123]`.
 
     [.toto, .titi, 12] :
         {"toto": 5, "titi": 10 }  --> [5, 10, 12] 
@@ -128,6 +130,9 @@ can be written as `[.toto, .titi, 123]`.
         ["A","B","C"]  --> "B"
         ["a"]          ... undefined
 
+The vector notation is introduced to satisfy JSON syntax and, for example,
+is not supported in _code derivation_ (explained below).
+
 ---
 
 ### Pragmatic extensions, aka "standard library"
@@ -172,8 +177,8 @@ can be written as `[.toto, .titi, 123]`.
         "[1,2.11,0.3e-32]" --> [1,2.11,3e-33]
 
 
-- other predefined parial functions are: `DIV`, `FDIV`, `CONS`, `SNOC`, `toDateMsec`,
-  `toDateStr`, and `_log!`.
+- other predefined parial functions are: `DIV`, `FDIV`, `CONS`,
+  `SNOC`, `toDateMsec`, `toDateStr`, and `_log!`.
 
 ---
 
@@ -183,7 +188,8 @@ can be written as `[.toto, .titi, 123]`.
       max = <SNOC [.0, .1 max] <GT.0, .1>, .0> ;
       factorial = < [(),0] GT .0 [dec factorial, ()] TIMES, 1 >;
 
-_Codes_ (prefixed by `$`) can be defined by taged union and product. E.g.:
+### Codes (schemas, i.e., _non-functional types_)
+_Codes_ (prefixed by `$`) can be defined by tagged union and product. E.g.:
 
 
       $nat = <nat 1, {} 0>;
@@ -192,18 +198,67 @@ _Codes_ (prefixed by `$`) can be defined by taged union and product. E.g.:
       suc = {$nat 1};
       add = $pair <{.x.1 x, .y suc y} add, .y>;
 
+Two codes are considered equal when they are isomorphic (preserving
+union/product and field names). E.g., `$pair`, `${nat y, nat x}`, and
+`${<nat 1, {} 0> x, nat y}` are all equal.
+
 #### Basic extension codes
 
-Since _basic extension_ introduces integers, booleans, and strings, there are three
-predefined types: `int`, `bool`, and `string`. A vector product code can also be defined
-by `[ codeExp ]`. All members of the vector are the same code. E.g.,
+Since _basic extension_ introduces integers, booleans, and strings,
+there are three predefined types: `int`, `bool`, and `string`. A
+vector product code can also be defined by `[ codeExp ]`. All members
+of the vector are the same code. E.g.,
 
      $intVector = [ int ];
      $boolVector = [ bool ];
      $tree = [ tree ];
 
-     emptyList? = $intVector $[ string ]; -- as only an empty vector can be a vector
-                                          -- of integers and a vector of strings
+### Code derivation and Patterns
+
+Intuitively, a _pattern_ represents some set of contraints on
+codes. For example, expression `.toto` is a projection from a value of
+a product or a union with field `toto`.  Therefore, expression `.toto`
+introduces two patterns `p_i` and `p_o` (for input and output codes,
+respectively); `p_o` imposes no constraint on code, however `p_i` is a
+product or union code with field `toto` leading to a code fulfilling
+`p_o`, i.e., something like `< ? toto, ... >` or `{ ? toto, ... }`.
+
+         .toto
+     p_i       p_o
+
+In a more complex expression each (occurrence of) subexpression will
+introduce some new patterns.  
+For example, concider `<.toto, ()>`:
+
+        <    .toto    ,    ()    >
+     p1   p2       p3   p4    p5   p6
+
+where `p1` is the pattern for the input code of the whole expression,
+and `p6` is the pattern for the output.  We can deduce that patterns
+(`p1`, `p2`, `p4`) defines the same code, as well as (`p6`, `p5`, `p3`),
+because union combines partial functions with the same input and output codes.
+Identity, `()`, implies that (`p4`, `p5`) define the
+same code.  That means that in our expression, we deal with only one
+code, `c`, product or union, with field `toto` of type `c`, i.e.,
+
+        $c = < c toto, ... >;
+
+or
+
+        $c = { c toto, ... };
+
+Since the product code pattern (i.e., latter case) doesn't admmit any
+(finite) value, we conclude that the code `c` is a union (i.e.,
+former case).
+
+For a given `kScript`, code derivation (as any static analysis) can
+fail, indicating that the script is invalid.  In some other cases the
+code derivation can succeed even to the point of reducig every pattern
+to a single code making the program fully annotated by codes.
+
+For now, `code derivation` is supported by the core language, i.e., `composition`,
+`projection` and `union` with product and tagged union types.
+
 ---
 
 ### List comprehension on vectors (experimental!)
@@ -259,8 +314,7 @@ times value `x` appears in the list. (see `Examples/list-comprehension.k` for a
         ."field name"
         .4
 
-    The function is defined only if its argument is a structure with
-the field (or a vector with the index).
+   The function is defined if its argument "has" the field.
 
 2. _constants_, literals for Strings, Booleans, and
    Integers. Examples:

package/TODO.md

@@ -0,0 +1,54 @@
+# TODO list
+
+- [ ] Incremental compilation
+- [ ] After `annotation` is done, find fully closed patterns, turn them into codes, then rerun
+  the code minimization step
+- [ ] Named relations can be polymorphic:
+  -- can we introduce polymorphic patterns? E.g.,: `{ .x if, .y then} .then`.
+    Here, the input pattern could be "open" product with two fields `.x` and `.y`, end the ouput pattern could be the pattern of field `.y`.
+  -- should we introduce a scope (e.g., syntactic or dynamic?) for all calls to the relation and
+    run annotations for all scopes separately?
+- [ ] Implement support for different relations under a same name as long as they have 
+  "very" different input or output patterns.
+- [ ] In type graphs, we should detect cycles over only product types and reject such programs, e.g.,:
+
+  ```k
+  $boo = {{} _, boo b};
+  ```
+
+---
+
+## Type system
+
+Example:
+
+```Examples/pats.k
+xy = .x y;
+y = .y;
+$A = < {} a, {} other >;
+$B = < {} b, {} other >;
+$ya = < {} a, $A y >;
+$yb = < {} b, $B y >;
+$input = {{ya x, {} y} one, {yb x, {} y} two};
+$input {.one xy one, .two xy two}
+```
+
+We would like to correctly type the above program as `$input -> { A one, B two }`.
+
+filters for typing `__main__`:
+
+```?
+          __main__
+         0  /  \ 1
+           /    \
+   $input         {.one xy one, .two xy two}
+ 2       3       4          /   \    5          
+                          /      \
+                 (.one xy)         (.two xy)  
+                    / \               / \
+              6    /   \ 7       8   /   \ 9
+                  /     \           /     \
+              .one       xy       .two       xy
+            10    11   12  13    14    15   16  17
+
+```