		{
		"name": "@fraczak/k",
		"version": "2.1.6",
		"version": "3.0.1",
		"description": "k-language for JSON-like data transformation",
		@@ -8,3 +8,3 @@ "main": "index.mjs",
		"prepare": "jiwson -m es6 parser.jison -o parser.mjs",
		"test": "node test.mjs"
		"test": "node test.mjs; for f in Code-derivation-tests/*.mjs; do echo $f; node $f; done; node test-fingerprint.mjs"
		},
		@@ -11,0 +11,0 @@ "repository": {

README.md

		@@ -79,5 +79,6 @@ # k-language
		- 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`.

		@@ -122,4 +123,5 @@ Comments can be introduced by `//`, `--`, `%`, or `#` and extends to
		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]`.

		@@ -133,2 +135,5 @@ [.toto, .titi, 12] :

		The vector notation is introduced to satisfy JSON syntax and, for example,
		is not supported in _code derivation_ (explained below).

		---
		@@ -178,4 +183,4 @@

		- 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!`.

		@@ -190,3 +195,4 @@ ---

		_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.:

		@@ -200,7 +206,12 @@

		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.,

		@@ -211,4 +222,48 @@ $intVector = [ int ];

		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.

		---
		@@ -269,4 +324,3 @@

		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.

		@@ -273,0 +327,0 @@ 2. _constants_, literals for Strings, Booleans, and

codes.mjs