@fraczak/k 2.1.5 → 3.0.1

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
+
+```

package/TYPES.md

@@ -0,0 +1,32 @@
+# What if we concider partial functions as filter-to-filter mappings?
+
+## Examples
+
+```k
+.x :: ( X x, ... ) -> X
+{ f1 x1, f2 x2, ..., fn xn } :: X -> { f1(X) x1, f2(X) x2, ..., fn(X) xn }
+{ f x } :: X -> < f(X) x, ... >
+< f1, f2, ..., fn > :: X -> f1(X) // f1 == f2 == ... == fn
+[ f1, f2, ..., fn ] :: X -> [f1(X)] // f1 == f2 == ... == fn
+$code :: 
+```
+
+Let's consider the following example:
+
+```k
+$nat = < {} _, nat s >;
+z = {{} _};   -- X -> <{} _, ...>
+s = {() s};   -- X -> <X s, ...>
+
+add = 
+  <
+    {.x ._ if, .y then} .then,
+    {.x .s x, .y s y } add
+  >
+;
+
+double = {() x, () y} add;
+
+z s s $nat double;
+```
+