No OneTemporary
Actions

Subscribers

None

File Metadata

Created: Sat, Mar 14, 4:43 AM

View Options

	diff --git a/config/default.json b/config/default.json
	index 631feec..d52c52a 100644
	--- a/config/default.json
	+++ b/config/default.json
	@@ -1,74 +1,74 @@
	{
	"containers": {
	"id": {
	"implementations": "containers_impl",
	"linkedlist": "linkedlist"
	},

	"impl": {
	"solid": "solid",
	"onthefly": "onthefly"
	}
	},

	"logging": {
	"id": "logging"
	},

	"function-entry": "entry",

	"transcend": {
	"bindings" : {
	"variable": "bind",
	"function": "bind_func",
	"scope": "bind_scope",
	"function_demand" : "bind_function_demand",
	"scope_decision": "bind_scope_decision"
	},

	"context" : {
	"decisions":{
	"dependent": "resolution_dependency"
	}
	},

	"nonevalue": "nonevalue",
	"ret": {
	"symbol": "retv",
	"tag": "ret"
	}
	},

	"tests": {
	"template": "default",

	"templates": {
	- "troubleshooting":"Exploitation.Doc_ExampleEov_1",
	+ "troubleshooting":"*",
	"documentation":"Modules.Doc_:Modules_API.Doc_:Interpretation.Doc_:AST.Doc_:Loop.Doc_:LateReasoning.Doc_:Latex.Doc_:Polymorphs.Doc_:Transcend.Doc_:ASTCorrespondence.Doc_:Virtualization.Doc_:Exploitation.Doc_:Communication.Doc_:Introduction.",
	"default": "*",
	"ast": "AST.*",
	"effects": "Effects.*",
	"basic": "Attachments.*",
	"compilation": "Compilation.*",
	"communication": "Communication.*",
	"cfa": "CFA.*",
	"containers": "Containers.*",
	"dfa": "DFA.*",
	"diagnostic": "Diagnostic.*",
	"dsl": "Association.:Interpretation.",
	"exploitation": "Exploitation.*",
	"ExpressionSerializer": "ExpressionSerializer.*",
	"externc": "InterfaceExternC.*",
	"loops": "Loop.*",
	"latereasoning": "LateReasoning.*",
	"latex": "Latex.*",
	"modules": "Modules.*",
	"polymorphs": "Polymorphs.*",
	"intrinsic-query": "Types.SlaveTypes:Association.TypedQuery",
	"types": "Types.*",
	"virtualization": "Virtualization.*",
	"vendorsAPI/clang": "ClangAPI.*",
	"vendorsAPI/xml2": "libxml2.*"
	}
	}
	}
	diff --git a/cpp/tests/ast.cpp b/cpp/tests/ast.cpp
	index 5072b32..1a6c65a 100644
	--- a/cpp/tests/ast.cpp
	+++ b/cpp/tests/ast.cpp
	@@ -1,229 +1,254 @@
	/* Any copyright is dedicated to the Public Domain.
	* http://creativecommons.org/publicdomain/zero/1.0/
	*
	* ast.cpp
	*
	* Created on: Jun 11, 2015
	* Author: pgess <v.melnychenko@xreate.org>
	*/


	#include "supplemental/docutils.h"
	#include "xreatemanager.h"
	#include "main/Parser.h"
	#include "supplemental/defines.h"
	#include "gtest/gtest.h"

	using namespace std;
	using namespace xreate;
	using namespace xreate::grammar::main;

	TEST(AST, Containers1) {
	FILE* input = fopen("scripts/containers/Containers_Implementation_LinkedList1.xreate", "r");
	Scanner scanner(input);
	Parser parser(&scanner);
	parser.Parse();
	assert(!parser.errors->count && "Parser errors");

	fclose(input);
	}

	TEST(AST, InterfacesDataCFA) {
	XreateManager* man = XreateManager::prepare
	("interface(cfa){\n"
	" operator map :: annotation1.\n"
	"}");

	auto answer = man->root->__interfacesData.equal_range(CFA);
	EXPECT_EQ(1, std::distance(answer.first, answer.second));

	Expression&& scheme = move(answer.first->second);

	EXPECT_EQ(Operator::MAP, scheme.op);
	EXPECT_EQ("annotation1", scheme.getOperands().at(0).getValueString());
	}

	TEST(AST, syntax_recognizeIdentifiers) {
	XreateManager* man = XreateManager::prepare(R"Code(
	test= function(a:: num):: num; entry {
	a = b:: int.
	b = 8:: int.

	a
	}
	)Code");
	}

	TEST(AST, syntax_operatorIndex) {
	XreateManager* man = XreateManager::prepare(R"Code(
	test= function(a:: num):: num; entry {
	b = a[1].
	b
	}
	)Code");
	}

	TEST(AST, Variants_switch) {
	XreateManager* man = XreateManager::prepare(R"Code(
	Color = type variant{Blue, White, Green}.

	main = function:: int {
	x = White()::Color.

	switch variant(x)::int
	case (Green) {0}
	case (White) {1}
	case (Blue){2}
	}
	)Code");

	Expression e = man->root->findFunction("main")->getEntryScope()->getBody();
	ASSERT_EQ(4, e.getOperands().size());
	ASSERT_EQ(3, e.blocks.size());
	}

	TEST(AST, DISABLED_InterfacesDataDFA) { }

	TEST(AST, DISABLED_InterfacesDataExtern) { }

	TEST(AST, Doc_LiteralsAndExpressions) {
	XreateManager* man = XreateManager::prepare(
	R"Code(

	Record1 = type {year:: int, month:: string}.
	isOdd = function(x :: int) :: bool {true}

	test = function:: bool; entry {
	x1 = 5 :: int.
	x2 = "Nimefurahi kukujua":: string.
	x3 = {year = 1934, month = "april"}:: Record1.
	x4 = {16, 8, 3} :: [int].
	x41 = [1..18]:: [int].
	x5 = 8>=3:: bool.
	x6 = "Blue" <> "Green" :: bool.
	x7 = -true:: bool.
	colors = {"Green", "Blue"} :: [string].
	color = colors[0] :: string.
	date = {year = 1934, month = "april"}:: Record1. year = date["year"] :: int.
	a = 0::int. b = 0 :: int.
	x7 = a - b:: int.
	result = isOdd(6) :: bool.

	true
	}

	)Code");

	ASSERT_TRUE(true);
	}

	TEST(AST, Doc_CodeBlocks1) {
	XreateManager* man = XreateManager::prepare(
	getDocumentationExampleById("documentation/Syntax/syntax.xml", "CodeBlocks1"));

	FnNoArgs resultFn = (FnNoArgs) man->run();
	int resultExpected = resultFn();
	ASSERT_EQ(12, resultExpected);
	}

	TEST(AST, Doc_Functions1) {
	XreateManager* man = XreateManager::prepare(
	getDocumentationExampleById("documentation/Syntax/syntax.xml", "Functions1"));

	ASSERT_TRUE(true);
	}

	TEST(AST, Doc_FunctionSpecializations1) {
	XreateManager* man = XreateManager::prepare(
	getDocumentationExampleById("documentation/Syntax/syntax.xml", "FunctionSpecialization1"));

	ASSERT_TRUE(true);
	}

	TEST(AST, Doc_BranchStatements) {
	string code_IfStatement1 = getDocumentationExampleById("documentation/Syntax/syntax.xml", "IfStatement1");
	string code_SwitchStatement1 = getDocumentationExampleById("documentation/Syntax/syntax.xml", "SwitchStatement1");

	string code =
	R"Code(
	test = function:: int; entry
	{
	question = "Favorite color?":: string.
	monthNum = 2:: int.

	%IfStatement1
	%SwitchStatement1

	monthName
	}
	)Code";
	replace(code, "%IfStatement1", code_IfStatement1);
	replace(code, "%SwitchStatement1", code_SwitchStatement1);

	XreateManager* man = XreateManager::prepare(move(code));

	ASSERT_TRUE(true);
	}

	TEST(AST, Doc_LoopStatements) {
	string code_LoopStatement1 = getDocumentationExampleById("documentation/Syntax/syntax.xml", "LoopStatement1");
	string code_LoopStatement2 = getDocumentationExampleById("documentation/Syntax/syntax.xml", "LoopStatement2");
	string code_FoldStatement1 = getDocumentationExampleById("documentation/Syntax/syntax.xml", "FoldStatement1");
	string code_MapStatement1 = getDocumentationExampleById("documentation/Syntax/syntax.xml", "MapStatement1");

	string code =
	R"Code(
	test = function:: int; entry
	{
	%LoopStatement1
	%LoopStatement2
	%FoldStatement1
	%MapStatement1

	min
	}
	)Code";

	replace(code, "%LoopStatement1", code_LoopStatement1);
	replace(code, "%LoopStatement2", code_LoopStatement2);
	replace(code, "%FoldStatement1", code_FoldStatement1);
	replace(code, "%MapStatement1", code_MapStatement1);
	XreateManager::prepare(move(code));

	ASSERT_TRUE(true);
	}

	TEST(AST, Doc_Types){
	string code = getDocumentationExampleById("documentation/Syntax/syntax.xml", "Types1");
	XreateManager::prepare(move(code));

	ASSERT_TRUE(true);
	}

	TEST(AST, Doc_Variants1){
	string code_Variants1 = getDocumentationExampleById("documentation/Syntax/syntax.xml", "Variants1");
	XreateManager::prepare(move(code_Variants1));

	ASSERT_TRUE(true);
	}

	TEST(AST, Doc_VariantsSwitch1){
	string code_Variants1 = getDocumentationExampleById("documentation/Syntax/syntax.xml", "VariantsSwitch1");
	XreateManager::prepare(move(code_Variants1));

	ASSERT_TRUE(true);
	}

	TEST(AST, Doc_RecField1){
	string code_Variants1 = getDocumentationExampleById("documentation/Syntax/syntax.xml", "RecField1");
	XreateManager::prepare(move(code_Variants1));

	ASSERT_TRUE(true);
	}

	TEST(AST, Doc_RecUpdate1){
	string code_Variants1 = getDocumentationExampleById("documentation/Syntax/syntax.xml", "RecUpdate1");
	XreateManager::prepare(move(code_Variants1));

	ASSERT_TRUE(true);
	+}
	+
	+TEST(AST, Doc_Versions1){
	+ string code_Variants1 = getDocumentationExampleById("documentation/Syntax/syntax.xml", "Versions1_1");
	+ string code_Variants2 = getDocumentationExampleById("documentation/Syntax/syntax.xml", "Versions1_2");
	+
	+ string code = R"Code(
	+test = function:: int; entry
	+{
	+ <BODY>
	+ y
	+})Code";
	+
	+ {
	+ XreateManager* man = XreateManager::prepare(move(code_Variants1));
	+ man->run();
	+ delete man;
	+ ASSERT_TRUE(true);
	+ }
	+
	+ {
	+ replace(code, "<BODY>", code_Variants2);
	+ auto man = details::tier1::XreateManager::prepare(move(code));
	+ ASSERT_DEATH(man->analyse(), ".versions graph.");
	+ }
	}
	\ No newline at end of file
	diff --git a/cpp/tests/introduction.cpp b/cpp/tests/introduction.cpp
	index 64f4d2b..d28a716 100644
	--- a/cpp/tests/introduction.cpp
	+++ b/cpp/tests/introduction.cpp
	@@ -1,25 +1,28 @@
	/* Any copyright is dedicated to the Public Domain.
	* http://creativecommons.org/publicdomain/zero/1.0/
	*
	* Introduction.cpp
	*
	* Created on: March 2019
	* Author: pgess <v.melnychenko@xreate.org>
	*/

	#include "xreatemanager.h"
	#include "transcendlayer.h"
	#include "supplemental/docutils.h"
	#include <gtest/gtest.h>

	using namespace xreate;
	using namespace std;

	TEST(Introduction, Doc_Example_1){
	+ string codePreamble = R"CODE(
	+ zeroDivisionErrCode = function:: int {0}
	+)CODE";
	string example = getDocumentationExampleById("documentation/index.xml", "Example_1");
	string rules = getDocumentationExampleById("documentation/index.xml", "Transcend_Example_1");
	- std::unique_ptr<XreateManager> man(XreateManager::prepare(move(example)));
	+ std::unique_ptr<XreateManager> man(XreateManager::prepare(codePreamble + example));
	man->transcend->addRawScript(move(rules));

	int (* main)() = (int (*)()) man->run();
	}
	\ No newline at end of file
	diff --git a/cpp/tests/latex.cpp b/cpp/tests/latex.cpp
	index 77db129..be55f08 100644
	--- a/cpp/tests/latex.cpp
	+++ b/cpp/tests/latex.cpp
	@@ -1,328 +1,358 @@
	/* Any copyright is dedicated to the Public Domain.
	* http://creativecommons.org/publicdomain/zero/1.0/
	*
	* Author: pgess <v.melnychenko@xreate.org>
	* Created on June 25, 2018, 5:42 PM
	*
	* \file latex.cpp
	* \brief Testing of latex
	*/

	#include "xreatemanager.h"
	#include "pass/compilepass.h"
	#include "transcendlayer.h"
	#include "query/latex.h"
	#include "compilation/latex.h"
	#include "aux/xreatemanager-decorators.h"
	#include "compilation/scopedecorators.h"
	#include "llvmlayer.h"
	#include "supplemental/docutils.h"
	+#include "supplemental/defines.h"

	#include <boost/format.hpp>
	#include <gtest/gtest.h>

	using namespace xreate::latex;
	using namespace xreate::latereasoning;
	using namespace xreate::compilation;
	using namespace xreate;
	using namespace std;

	TEST(Latex, Script_NestedScopePropagation_1) {
	std::string program =
	R"CODE(
	import raw("scripts/cfa/context.lp").
	fn = function:: int; entry
	{
	context:: test1.
	if(1==11)::int {2} else {3}
	}
	)CODE";

	std::unique_ptr<details::tier1::XreateManager> man(details::tier1::XreateManager::prepare(move(program)));

	CodeScope* blockTrue = man->root->findFunction("fn")->getEntryScope()->getBody().blocks.front();
	auto blockTrueP = man->transcend->pack(blockTrue);
	boost::format formatAlias("alias(%1%, %2%).");
	man->transcend->addRawScript((formatAlias % blockTrueP % "block1").str());
	man->transcend->addRawScript(
	R"SCRIPT(
	success1:- bind_scope(Block1, test1, strong); alias(Block1, block1).
	)SCRIPT");
	man->analyse();

	ASSERT_EQ(1, man->transcend->query("success1").size());
	}

	TEST(Latex, Script_DemAndDecision_1) {
	std::string program =
	R"CODE(
	import raw("scripts/cfa/context.lp").

	a = function:: int
	{
	context:: forC(a).
	c()
	}

	b = function:: int
	{
	context:: forC(b).
	c()
	}

	c = function:: int {0}

	main = function:: int; entry
	{
	a() + b()
	}
	)CODE";

	std::unique_ptr<details::tier1::XreateManager> man(details::tier1::XreateManager::prepare(move(program)));

	CodeScope* blockC = man->root->findFunction("c")->getEntryScope();
	auto blockCP = man->transcend->pack(blockC);
	boost::format formatAlias("alias(%1%, %2%).");
	man->transcend->addRawScript((formatAlias % blockCP % "blockC").str());
	man->transcend->addRawScript(
	R"SCRIPT(
	latex_scope_demand(BlockC, forC):- alias(BlockC, blockC).
	latex_registered_subjects(forC, Variant):- bind_scope(_, Variant, strong); Variant = forC(_).
	)SCRIPT");
	man->analyse();

	ASSERT_EQ(1, man->transcend->query("latex_fn_demand").size());
	ASSERT_EQ(2, man->transcend->query("latex_decision").size());
	}

	TEST(Latex, LatexQuery_getFnDemand_1){
	std::string program =
	R"CODE(
	import raw("scripts/cfa/context.lp").
	main = function:: int; entry
	{
	context:: alias(blockMain).
	0
	}
	)CODE";

	std::unique_ptr<details::tier1::XreateManager> man(details::tier1::XreateManager::prepare(move(program)));
	man->transcend->addRawScript(
	R"SCRIPT(
	latex_scope_demand(BlockC, forC):- bind_scope(BlockC, alias(blockMain), strong).
	latex_registered_subjects(forC, decisionSome).
	)SCRIPT");

	LatexQuery* query = new LatexQuery();
	man->transcend->registerQuery(query, QueryId::LatexQuery);
	man->analyse();

	Demand demand = query->getFnDemand("main");
	ASSERT_EQ(1, demand.size());
	ASSERT_STREQ("forC", demand.front().c_str());
	}

	TEST(Latex, LatexQuery_getDecision_static_1){
	std::string program =
	R"CODE(
	import raw("scripts/cfa/context.lp").
	a = function:: int {context::decisionSome. c()}
	b = function:: int {c()}
	c = function:: int {context:: alias(blockC). 0}
	)CODE";

	std::unique_ptr<details::tier1::XreateManager> man(details::tier1::XreateManager::prepare(move(program)));
	man->transcend->addRawScript(
	R"SCRIPT(
	latex_scope_demand(BlockC, forC):- bind_scope(BlockC, alias(blockC), strong).
	latex_registered_subjects(forC, decisionSome).
	)SCRIPT");

	LatexQuery* query = new LatexQuery();
	man->transcend->registerQuery(query, QueryId::LatexQuery);
	man->analyse();

	LateAnnotation decisionLA = query->getDecision("forC", man->root->findFunction("a")->getEntryScope());
	auto decisionGS = decisionLA.select({}, man->root, man->transcend);
	ASSERT_TRUE(decisionGS);

	decisionGS->print(cout);
	cout << endl;
	auto decisionTuple = man->transcend->parse<Gringo::Symbol, Gringo::Symbol, string>(*decisionGS);
	string decision = get<2>(decisionTuple);
	ASSERT_STREQ("decisionSome", decision.c_str());
	}

	TEST(Latex, Compilation_1) {
	std::string program =
	R"CODE(

	a = function:: int
	{0}

	main = function:: int; entry
	{
	a()
	}
	)CODE";

	string script =
	R"SCRIPT(
	latex_fn_demand(%1%, subject1).
	latex_decision(%2%, subject1, 5).
	latex_registered_subjects(subject1, 1).
	latex_registered_subjects(subject1, 5).
	)SCRIPT";

	typedef LatexBruteFunctionDecorator<compilation::BasicFunctionUnit> FnImpl;
	typedef LatexBruteScopeDecorator<compilation::CachedScopeDecorator<compilation::BasicCodeScopeUnit>> ScopeImpl;

	std::unique_ptr<details::tier1::XreateManager> man(details::tier1::XreateManager::prepare(move(program)));
	ScopePacked scopeMainP = man->transcend->pack(man->root->findFunction("main")->getEntryScope());
	boost::format format(script);
	man->transcend->addRawScript((format % "a" % scopeMainP).str());
	man->transcend->registerQuery(new LatexQuery(), QueryId::LatexQuery);
	man->analyse();

	std::unique_ptr<CompilePass> compiler(new compilation::CompilePassCustomDecorators<FnImpl, ScopeImpl>(man.get()));
	compiler->run();
	man->llvm->initJit();
	int(fnMain)() = (int()())man->llvm->getFunctionPointer(compiler->getEntryFunction());
	ASSERT_EQ(0, fnMain());
	}

	//
	//TEST(Latex, Full1) {
	// std::string program =
	// R"CODE(
	// import raw("scripts/cfa/context.lp").
	//
	// a = function:: int
	// {
	// context:: forC(a).
	// c()
	// }
	//
	// b = function:: int
	// {
	// context:: forC(b).
	// c()
	// }
	//
	// c = function:: int {0}
	//
	// main = function:: int; entry
	// {
	// a() + b()
	// }
	// )CODE";
	//
	// string script =
	// R"SCRIPT(
	// alias(%1%, scopeC).
	// latex_scope_demand(ScopeC, forC) :- alias(ScopeC, scopeC).
	// latex_registered_subjects(forC, forC(a)).
	// latex_registered_subjects(forC, forC(b)).
	// )SCRIPT";
	//
	// typedef LatexBruteFunctionDecorator<compilation::BasicFunctionUnit> FnImpl;
	// typedef LatexBruteScopeDecorator<compilation::CachedScopeDecorator<compilation::BasicCodeScopeUnit>> ScopeImpl;
	//
	// std::unique_ptr<details::tier1::XreateManager> man(details::tier1::XreateManager::prepare(move(program)));
	// ScopePacked scopeMainP = man->transcend->pack(man->root->findFunction("main")->getEntryScope());
	// auto scopeCP = man->transcend->pack(man->root->findFunction("c")->getEntryScope());
	// boost::format format(script);
	// man->transcend->addRawScript((format %scopeCP).str());
	// man->transcend->registerQuery(new LatexQuery(), QueryId::LatexQuery);
	// man->analyse();
	//
	// std::unique_ptr<CompilePass> compiler(new compilation::CompilePassCustomDecorators<FnImpl, ScopeImpl>(man.get()));
	// compiler->run();
	// man->llvm->print();
	//}
	//
	TEST(Latex, Compilation_TransitFn1){
	std::string program =
	R"CODE(
	import raw("scripts/cfa/context.lp").

	branchA = function:: int
	{
	context:: sink_a.
	fnTransit()
	}

	branchB = function:: int
	{
	context:: sink_b.
	fnTransit()
	}

	fnSink = function:: int {0}
	fnTransit = function:: int {fnSink()}

	main = function:: int; entry
	{
	branchA() + branchB()
	}
	)CODE";

	string script =
	R"SCRIPT(
	alias(scopeSink, %1%).
	latex_scope_demand(ScopeSink, sink):- alias(scopeSink, ScopeSink).
	latex_registered_subjects(sink, sink_a).
	latex_registered_subjects(sink, sink_b).
	)SCRIPT";

	typedef LatexBruteFunctionDecorator<compilation::BasicFunctionUnit> FnImpl;
	typedef LatexBruteScopeDecorator<compilation::CachedScopeDecorator<compilation::BasicCodeScopeUnit>> ScopeImpl;

	std::unique_ptr<details::tier1::XreateManager> man(details::tier1::XreateManager::prepare(move(program)));
	CodeScope* scopeSink = man->root->findFunction("fnSink")->getEntryScope();
	auto scopeSinkP = man->transcend->pack(scopeSink);
	ScopedSymbol argLatexSS{1, -1};
	Symbol argLatexS{argLatexSS, scopeSink};
	man->transcend->pack(argLatexS);
	boost::format format(script);
	man->transcend->addRawScript((format %scopeSinkP).str());
	man->transcend->registerQuery(new LatexQuery(), QueryId::LatexQuery);
	man->analyse();

	std::unique_ptr<CompilePass> compiler(new compilation::CompilePassCustomDecorators<FnImpl, ScopeImpl>(man.get()));
	compiler->run();
	man->llvm->print();
	man->llvm->initJit();
	int(fnMain)() = (int()()) man->llvm->getFunctionPointer(compiler->getEntryFunction());
	int valueActual = fnMain();
	ASSERT_EQ(0, valueActual);
	}

	TEST(Latex, Doc_Examples1){
	std::string program = getDocumentationExampleById("documentation/Concepts/context.xml", "Examples_1");
	std::unique_ptr<details::tier1::XreateManager> man(details::tier1::XreateManager::prepare(move(program)));
	}

	TEST(Latex, Doc_Examples2){
	std::string program = getDocumentationExampleById("documentation/Concepts/context.xml", "Examples_2");

	std::unique_ptr<details::tier1::XreateManager> man(details::tier1::XreateManager::prepare(move(program)));
	}

	TEST(Latex, Doc_ContextPropagation1){
	std::string program =getDocumentationExampleById("documentation/Concepts/context.xml", "ContextPropagation1");

	std::unique_ptr<details::tier1::XreateManager> man(details::tier1::XreateManager::prepare(move(program)));
	}

	TEST(Latex, Doc_ContextPropagation2){
	std::string program = getDocumentationExampleById("documentation/Concepts/context.xml", "ContextPropagation2");

	std::unique_ptr<details::tier1::XreateManager> man(details::tier1::XreateManager::prepare(move(program)));
	}

	TEST(Latex, Doc_Latex1){
	std::string program = getDocumentationExampleById("documentation/Concepts/context.xml", "Latex1");

	- std::unique_ptr<details::tier1::XreateManager> man(details::tier1::XreateManager::prepare(move(program)));
	+ string script =
	+R"SCRIPT(
	+ latef(compute).
	+
	+ latex_scope_demand(Scope, f_guarded(F)):-
	+ cfa_call(Scope, F);
	+ latef(F).
	+
	+ latex_registered_subjects(f_guarded(F), Guard):-
	+ cfa_function_specializations(F, Guard);
	+ latef(F).
	+
	+ late(TargetS, LatexParam, Guard, dfa_callguard(TargetS, Guard)):-
	+ dfa_callfn(TargetS, FnGuarded);
	+ latef(FnGuarded);
	+ latex_symbol(FnCallerBody, f_guarded(FnGuarded), LatexParam);
	+ TargetS=s(_,_, TargetScope);
	+ scope_fnbody(TargetScope, FnCallerBody);
	+ cfa_function_specializations(FnGuarded, Guard).
	+)SCRIPT";
	+
	+ auto man(XreateManager::prepare(move(program)));
	+ man->transcend->addRawScript(move(script));
	+ Fn3args fn = (Fn3args) man->run();
	+
	+ int resultActual = fn(1, 4, 3);
	+ ASSERT_EQ(7, resultActual);
	+
	+ resultActual = fn(0, 4, 3);
	+ ASSERT_EQ(1, resultActual);
	}
	\ No newline at end of file
	diff --git a/cpp/tests/supplemental/defines.h b/cpp/tests/supplemental/defines.h
	new file mode 100644
	index 0000000..f51b989
	--- /dev/null
	+++ b/cpp/tests/supplemental/defines.h
	@@ -0,0 +1,21 @@
	+/* Any copyright is dedicated to the Public Domain.
	+ * http://creativecommons.org/publicdomain/zero/1.0/
	+ *
	+ *
	+ * File: defines.h
	+ * Author: pgess
	+ *
	+ * Created on May 7, 2019, 8:11 PM
	+ */
	+
	+#ifndef DEFINES_H
	+#define DEFINES_H
	+
	+typedef int (*FnNoArgs)();
	+typedef int (*Fn1Args)(int);
	+typedef int (*Fn2args)(int, int);
	+typedef int (*Fn3args)(int, int, int);
	+
	+
	+#endif /* DEFINES_H */
	+
	diff --git a/documentation/Concepts/context.xml b/documentation/Concepts/context.xml
	index 8d1cd0a..5e7508a 100644
	--- a/documentation/Concepts/context.xml
	+++ b/documentation/Concepts/context.xml
	@@ -1,312 +1,303 @@
	<?xml version="1.0" encoding="UTF-8"?>
	<chapter version="5.1" xmlns="http://docbook.org/ns/docbook"
	xmlns:xlink="http://www.w3.org/1999/xlink"
	xmlns:xila="http://www.w3.org/2001/XInclude/local-attributes"
	xmlns:xi="http://www.w3.org/2001/XInclude"
	xmlns:trans="http://docbook.org/ns/transclusion"
	xmlns:svg="http://www.w3.org/2000/svg"
	xmlns:m="http://www.w3.org/1998/Math/MathML"
	xmlns:html="http://www.w3.org/1999/xhtml"
	xmlns:db="http://docbook.org/ns/docbook">
	<?xxe-sn 2ahi4rjnvuo 1?>

	<title><?xxe-sn 2ahi4rjnvuo 2?>Context</title>

	<para><?xxe-sn 2ahi4rjnvuo 3?>Computer program, its internal states and
	- transitions between them can be looked at from two different points of view:
	- control flow and data flow. In order to express and employ control flow
	- related program's properties Xreate supports mechanism called
	- <emphasis><?xxe-sn 2axopn9e3uo 1?>context</emphasis> — ability to assign
	- transcend data to a code blocks in a way that related blocks in the CFG have
	- related contexts.</para>
	-
	- <para><?xxe-sn 2ahi4rjnvuo 5?>Code block's context is exhaustingly defined
	- as follows:</para>
	-
	- <itemizedlist>
	- <?xxe-sn 2ahi4rjnvuo 6?>
	-
	- <listitem>
	- <?xxe-sn 2ahi4rjnvuo 7?>
	-
	- <para><?xxe-sn 2ahi4rjnvuo 8?>Block's place within the code in terms of
	- hierarchy of all its respective parents.</para>
	- </listitem>
	-
	- <listitem>
	- <?xxe-sn 2ahi4rjnvuo 9?>
	-
	- <para><?xxe-sn 2ahi4rjnvuo a?>Historical data determined by previous
	- visited code blocks in terms of "caller-callee" relation graph.</para>
	- </listitem>
	- </itemizedlist>
	+ transitions between them can be looked at from two different sides: control
	+ flow and data flow. This chapter expands on a specific mechanism called
	+ <emphasis><?xxe-sn 2fkjzaz3pq8 1?>context</emphasis> to reflect control flow
	+ as well as a program's structure to facilitate optimizations, safety
	+ measures and supporting code. In simpler terms it is a tool to adjust a
	+ <emphasis><?xxe-sn 2fobxtahb0g 1?>service</emphasis> to serve the best
	+ particular needs of <emphasis><?xxe-sn 2fobxtahb0g 2?>clients</emphasis>
	+ that actually use it.</para>

	<para><?xxe-sn 2ahi4rjnvuo b?>Block level annotations are used to define
	- context and reason about it. See <link
	+ context and to reason about it. See <link
	xlink:href="/d/transcend/#code-blocks-and-context"><?xxe-sn 2ahi4rjnvuo c?>syntax</link>.</para>

	<section>
	<?xxe-sn 2ahi4rjnvuo d?>

	<title><?xxe-sn 2ahi4rjnvuo e?>Examples of Context Usage: Suggestions and
	Requirements</title>

	- <programlisting xml:id="Examples_1"><?xxe-sn 2ahi4rjnvuo f?>//someStringFn = function:: string {...}
	+ <para><?xxe-sn 2fkjzaz3pq8 2?>Context can be used to convey various forms
	+ of information as shown in a few examples below.</para>
	+
	+ <programlisting xml:id="Examples_1"><?xxe-sn 2ahi4rjnvuo f?>name="tests/latex.cpp: Latex.Doc_Examples1"
	+//someStringFn = function:: string {...}

	main = function:: string; entry
	{
	context:: env(utf8).
	+
	someStringFn()
	}</programlisting>

	- <para><?xxe-sn 2ahi4rjnvuo g?>In this example the annotation
	- <code><?xxe-sn 2ahi4rjnvuo h?>env(utf8)</code> conveys some information
	- about the block thus distinguishing it from the others, which allows to
	- apply specific compilation rules for this block. Suppose <code><?xxe-sn 2ahi4rjnvuo i?>someStringFn</code>
	- has different specializations for different environments. Now it's
	- possible to invoke specialization tailored for UTF8 environment. In this
	- case context can be viewed as a <emphasis><?xxe-sn 2axopn9e3uo 2?>suggestion</emphasis>
	- to pick up appropriate specialization.</para>
	-
	- <para><?xxe-sn 2ahi4rjnvuo j?>Also there is possibility to define expected
	- context properties:</para>
	-
	- <programlisting xml:id="Examples_2"><?xxe-sn 2ahi4rjnvuo k?>name - "...."
	-guard:: safe
	-{
	- crucialOperation = function:: int
	- {0}
	+ <para><?xxe-sn 2ahi4rjnvuo g?>In this example the <code><?xxe-sn 2fkjzaz3pq8 3?>env(utf8)</code>
	+ annotation conveys some information about a code block distinguishing it
	+ from others, which allows to apply specific compilation rules for this
	+ block. Suppose <code><?xxe-sn 2ahi4rjnvuo i?>someStringFn</code> has
	+ different specializations for different environments. Now it's possible to
	+ invoke a specialization tailored for the UTF-8 environment. In this case a
	+ context can be viewed as a <emphasis><?xxe-sn 2axopn9e3uo 2?>suggestion</emphasis>
	+ to pick up an appropriate specialization.</para>
	+
	+ <para><?xxe-sn 2ahi4rjnvuo j?>On the other hand, there is a possibility to
	+ define expected properties of a context:</para>
	+
	+ <programlisting xml:id="Examples_2"><?xxe-sn 2ahi4rjnvuo k?>name="tests/latex.cpp: Latex.Doc_Examples2"
	+guard:: only_safe_env
	+{
	+ crucialOperation = function:: bool
	+ {true}
	}

	-main = function:: int; entry
	+main = function:: bool; entry
	{
	context:: env(safe).
	crucialOperation()
	}</programlisting>

	<para><?xxe-sn 2ahi4rjnvuo l?>Function <code><?xxe-sn 2ahi4rjnvuo m?>crucialOperation</code>
	- has only one specialization <code><?xxe-sn 2ahi4rjnvuo n?>safe</code> in
	- the example. If the context does not provide required environment
	- <code><?xxe-sn 2ahi4rjnvuo o?>env(safe)</code>compiler can't find
	- appropriate specialization and reports compilation error. This is a way
	- for function to express <emphasis><?xxe-sn 2axopn9e3uo 3?>requirements</emphasis>
	- or contract to a context it works within.</para>
	+ has only one specialization <code><?xxe-sn 2ahi4rjnvuo n?>only_safe_env</code>
	+ in the example. If the context does not provide the required environment
	+ <code><?xxe-sn 2ahi4rjnvuo o?>env(safe)</code> the compiler can't find an
	+ appropriate specialization and reports a compilation error. This is a way
	+ for a function to express <emphasis><?xxe-sn 2axopn9e3uo 3?>requirements</emphasis>
	+ or a contract to a context it works within.</para>
	</section>

	<section>
	<?xxe-sn 2ahi4rjnvuo q?>

	<title><?xxe-sn 2ahi4rjnvuo r?>Context Propagation</title>

	<para><?xxe-sn 2ahi4rjnvuo s?><emphasis><?xxe-sn 2axopn9e3uo 4?>Context
	- propagation</emphasis> means that contexts of different blocks are
	- connected reflecting control flow. Context of a particular code block is
	- gathered from following sources:</para>
	+ propagation</emphasis> means that contexts of different blocks are related
	+ reflecting control flow. Context of a particular code block consists of
	+ the following:</para>

	<itemizedlist>
	<?xxe-sn 2axopn9e3uo 5?>

	<listitem>
	<?xxe-sn 2axopn9e3uo 6?>

	- <para><?xxe-sn 2axopn9e3uo 7?>Local context — annotations that are
	- defined within the block</para>
	+ <para><?xxe-sn 2axopn9e3uo 7?>Local context: annotations that are
	+ defined within the block.</para>
	</listitem>

	<listitem>
	<?xxe-sn 2axopn9e3uo 8?>

	<para><?xxe-sn 2axopn9e3uo 9?>Parent context. Block's context inherits
	- context of its parent reflecting block's place within a
	- program.</para>
	+ context of its parent block reflecting <emphasis><?xxe-sn 2fq6kae5o8w 6?>enclosing
	+ - nested</emphasis> code blocks relation.</para>
	</listitem>

	<listitem>
	<?xxe-sn 2axopn9e3uo a?>

	- <para><?xxe-sn 2axopn9e3uo b?>Client context. Blocks context also
	- includes caller's context reflecting control flow. It allows taking
	- into account in which context a given code is used.</para>
	+ <para><?xxe-sn 2axopn9e3uo b?>Client context. Block's context inherits
	+ a caller's context reflecting clients of a particular function or
	+ <emphasis><?xxe-sn 2fkjzaz3pq8 5?>caller-callee</emphasis> relation.
	+ It allows to take into account how functions are used.</para>
	</listitem>
	</itemizedlist>

	- <para><?xxe-sn 2ahi4rjnvuo u?>Example below</para>
	+ <para><?xxe-sn 2ahi4rjnvuo u?>An example below:</para>

	- <programlisting xml:id="ContextPropagation1"><?xxe-sn 2ahi4rjnvuo w?>name = "..."
	+ <programlisting xml:id="ContextPropagation1"><?xxe-sn 2ahi4rjnvuo w?>name="tests/latex.cpp: Latex.Doc_ContextPropagation1"
	//requires 'safe' context
	-guard:: safe
	+guard:: only_safe_env
	{
	crucialOperation = function(a:: int, b::int):: int
	{ 0 }
	}

	test = function:: int; entry {
	//blockA
	context:: env(safe).

	range = [1..10]:: [int].
	loop fold(range->x::int, 0->acc):: int {
	//blockB
	- crucialOperation(x, acc) // In the nested scope env(safe) context still accessible
	+ crucialOperation(x, acc)
	}
	} </programlisting>

	- <para><?xxe-sn 2ahi4rjnvuo x?>demonstrates context propagation to a nested
	- block which is exhibited by availability of a <code><?xxe-sn 2ahi4rjnvuo z?>env(safe)</code>
	- annotation in the context of the nested block <code><?xxe-sn 2ahi4rjnvuo 10?>blockB</code>
	- despite being defined in the <code><?xxe-sn 2ahi4rjnvuo 11?>blockA</code>.</para>
	+ <para><?xxe-sn 2ahi4rjnvuo x?>demonstrates context propagation. There are
	+ no compilation errors for the context of <code><?xxe-sn 2fkjzaz3pq8 6?>blockB</code>
	+ contains inherited property <code><?xxe-sn 2fkjzaz3pq8 7?>env(safe)</code>
	+ defined in <code><?xxe-sn 2fkjzaz3pq8 8?>blockA</code>.</para>
	+
	+ <para><?xxe-sn 2ahi4rjnvuo 12?>Another case is when a callee inherits a
	+ caller's context. The example below demonstrates this:</para>
	+
	+ <programlisting xml:id="ContextPropagation2"><?xxe-sn 2ahi4rjnvuo 14?>name="tests/latex.cpp: Latex.Doc_ContextPropagation2", lines=15
	+guard:: units(mm)
	+{
	+ lengthToSI = function(x:: float):: int
	+ { x / 1000 }
	+}

	- <para><?xxe-sn 2ahi4rjnvuo 12?>Another case is propagation from caller to
	- a callee. It means context propagates through "caller/callee" relation —
	- callee inherits caller context. The example below demonstrates
	- this:</para>
	+guard:: units(min)
	+{
	+ timeToSI = function(x:: float):: int
	+ { x * 60 }
	+}

	- <programlisting xml:id="ContextPropagation2"><?xxe-sn 2ahi4rjnvuo 14?>name = "..."
	-toSI = function(x:: int):: int
	- { 0 }
	+guard:: units(m, sec)
	+{
	+ velocityToEnv = function(x:: float):: int
	+ { x }
	+}

	-calculate = function(x:: int):: int
	+calculateVelocity = function(length:: float, time:: float):: float
	{
	- y = toSI(x):: int.
	- y
	+ velocity_si = lengthToSI(length) / timeToSI(time).
	+
	+ velocityToEnv(velocity_si)
	}

	test = function:: int; entry
	{
	- context:: units(mm).
	- calculate(10)
	-} </programlisting>
	-
	- <para><?xxe-sn 2ahi4rjnvuo 15?>Suppose <code><?xxe-sn 2ahi4rjnvuo 16?>calculate()</code>works
	- with values measured in different units. It normalizes each value by
	- invoking <code><?xxe-sn 2ahi4rjnvuo 17?>toSI()</code> conversion. One
	- approach is to keep unit information for each variable independently. But
	- if we know that entire program or a part of it works only with specific
	- unit we can register it in a context, <code><?xxe-sn 2ahi4rjnvuo 18?>units(mm)</code>in
	- this example, letting functions <code><?xxe-sn 2ahi4rjnvuo 19?>calculate()</code>
	- and its callees inherit context allowing compiler to generate code
	- tailored for specific units only.</para>
	+ context:: length(units(mm)); time(units(min)); velocity(units(m, sec)).
	+ calculate(10, 2)
	+} </programlisting>
	+
	+ <para><?xxe-sn 2ahi4rjnvuo 15?>Function <code><?xxe-sn 2ahi4rjnvuo 16?>calculateVelocity()</code>
	+ works with values measured in different units. It normalizes each value by
	+ invoking the <code><?xxe-sn 2ahi4rjnvuo 17?>..toSI()</code> functions;
	+ after the computation is done it converts the result back to an
	+ environment's units. One approach is to keep unit information for each
	+ variable independently. But if we know that an entire program or a part of
	+ it works only with specific units we can register it in a context, such as
	+ <code><?xxe-sn 2ahi4rjnvuo 18?>length(units(mm))</code> in this example,
	+ letting the function <code><?xxe-sn 2ahi4rjnvuo 19?>calculateVelocity()</code>
	+ and its callees to inherit the context, thus allowing the compiler to
	+ generate code tailored to specific units only.</para>
	</section>

	<section>
	<?xxe-sn 2ahi4rjnvuo 1m?>

	- <title condition="incomplete"><?xxe-sn 2ahi4rjnvuo 1n?>Latex (Late
	- Context)</title>
	-
	- <note>
	- <?xxe-sn 2cpm8zia70g 3?>
	-
	- <para><?xxe-sn 2cpm8zia70g 4?>This section is still incomplete. It will
	- be reworked soon.</para>
	- </note>
	-
	- <para><?xxe-sn 2ahi4rjnvuo 1o?>Static(compile-time) context reasoning is
	- <emphasis><?xxe-sn 2ahi4rjnvuo 1p?>weak</emphasis> since it's able to
	- infer only partial context, consisting of properties that are true for all
	- possible paths leading in a CFG to a given block. Beyond that are entries
	- that depend on exact path in CFG. Such uncertainty is possible to resolve
	- during runtime once it's known which path exactly is chosen.</para>
	-
	- <para><?xxe-sn 2ahi4rjnvuo 1q?>To solve this problem <emphasis><?xxe-sn 2axopn9e3uo 11?>late
	- context</emphasis> is introduced - embedding into compiled code certain
	- instructions to gathered data on relevant occasion at runtime to determine
	- exact or <emphasis><?xxe-sn 2axopn9e3uo 12?>strong</emphasis>,
	+ <title><?xxe-sn 2ahi4rjnvuo 1n?>Latex (Late Context)</title>
	+
	+ <para><?xxe-sn 2ahi4rjnvuo 1o?>Importance of context as a development tool
	+ stems from the fact that if reflects among other thing a code's clients -
	+ by whom a given code is used. This allows to tailor a service based on
	+ specific clients' needs. Unfortunately this sort of information cannot be
	+ gathered fully at compile time. Compile time or static context reasoning
	+ is <emphasis><?xxe-sn 2ahi4rjnvuo 1p?>partial</emphasis> in a sense that
	+ it is capable of inferring only properties that are true for all possible
	+ paths leading in a CFG to a given block. Beyond that are properties that
	+ depend on an exact path in a CFG. Such uncertainty is possible to resolve
	+ only at runtime once it's known which path exactly is chosen. If a
	+ function is called from different locations, with each location having a
	+ different context, the context of the function in question is obviously
	+ different during each invocation. To solve this problem
	+ <emphasis><?xxe-sn 2axopn9e3uo 11?>late context</emphasis> (latex, in
	+ short) is introduced - a mechanism of embedding into compiled code certain
	+ instructions to gather data on relevant occasions at runtime to determine
	+ an exact or <emphasis><?xxe-sn 2axopn9e3uo 12?>strong</emphasis>
	context.</para>

	<para><?xxe-sn 2ahi4rjnvuo 1s?>Latex approach can be described as
	follows:</para>

	<itemizedlist>
	<?xxe-sn 2ahi4rjnvuo 1t?>

	<listitem>
	<?xxe-sn 2ahi4rjnvuo 1u?>

	- <para><?xxe-sn 2ahi4rjnvuo 1v?>Set of all possible context facts for
	- the given block is computed during compile time. Each such fact is
	- associated with code paths it holds for.</para>
	+ <para><?xxe-sn 2ahi4rjnvuo 1v?>A cloud of all possible context
	+ facts(<emphasis><?xxe-sn 2fobxtahb0g 3?>weak</emphasis> context) for a
	+ given block is computed during compile time. Each such fact is
	+ associated with code paths it is held for.</para>
	</listitem>

	<listitem>
	<?xxe-sn 2axopn9e3uo 13?>

	<para><?xxe-sn 2axopn9e3uo 14?>During execution the information is
	- gathered which facts are hold depending on actual code path.
	- Information stored in the late parameters. To convey late context data
	- the latex parameter is injected into function signature as hidden
	- parameter.</para>
	+ gathered which facts are hold depending on an actual code path. There
	+ are late parameters reserved to store late context. To pass on latex
	+ parameters, they are injected into functions as hidden
	+ parameters.</para>
	</listitem>

	<listitem>
	<?xxe-sn 2ahi4rjnvuo 1y?>

	- <para><?xxe-sn 2ahi4rjnvuo 1z?>Late parameter is used as guard for
	- late transcend facts context consists of.</para>
	+ <para><?xxe-sn 2ahi4rjnvuo 1z?>Late parameters are used internally to
	+ match against guards to determine which specialization to
	+ invoke.</para>
	</listitem>
	</itemizedlist>

	- <programlisting xml:id="Latex1"><?xxe-sn 2ahi4rjnvuo 21?>name = "..."
	-import raw ("core/control-context.lp").
	-
	-compute = function:: int
	- { 0 }
	+ <para><?xxe-sn 2fobxtahb0g 4?>An example:</para>

	-computeFast = function:: int {
	- context:: computation(fast).
	-
	- compute()
	-}
	-
	-computePrecisely = function:: int {
	- context:: computation(precise).
	-
	- compute()
	-}
	+ <programlisting xml:id="Latex1"><?xxe-sn 2ahi4rjnvuo 24?>name="tests/latex.cpp: Latex.Doc_Latex1", lines=15
	+import raw ("scripts/cfa/context.lp"). //enable context reasoning

	-test = function(cmnd:: int):: int; entry {
	- context:: arithmetic(iee754).
	-
	- if (cmnd > 0)::int {computePrecisely()} else {computeFast()}
	-}</programlisting>
	-
	- <para><?xxe-sn 2ahi4rjnvuo 22?>Static scope</para>
	-
	- <para><?xxe-sn 2ahi4rjnvuo 23?></para>
	-
	- <programlisting><?xxe-sn 2ahi4rjnvuo 24?>name = "..."
	-import raw ("core/control-context.lp")
	-case context:: computation(fast) {
	- compute = function:: num {
	- 0
	+guard:: sum
	+{
	+ compute = function(arg1:: int, arg2:: int):: int
	+ {
	+ arg1 + arg2
	}
	}

	-case context:: computation(precise) {
	- compute = function:: num {
	- 0
	+guard:: sub
	+{
	+ compute = function(arg1:: int, arg2:: int):: int
	+ {
	+ arg1 - arg2
	}
	}

	-executeComputation= function:: num {
	- compute()
	+executeComputation= function(arg1:: int, arg2:: int):: int
	+{
	+ compute(arg1, arg2) //`compute` has several specializations
	}

	-test = function(cmnd:: num):: num; entry {
	- if (cmnd > 0)::num {
	- context:: computation(fast).
	- executeComputation()
	+test = function(cmnd:: int, arg1:: int, arg2:: int):: int; entry
	+{
	+ if (cmnd > 0)::int
	+ {
	+ //scopeA
	+ context:: sum.
	+ executeComputation(arg1, arg2)

	- } else {
	- context:: computation(precise).
	- executeComputation()
	+ } else
	+ {
	+ //scopeB
	+ context:: sub.
	+ executeComputation(arg1, arg2)
	}
	}</programlisting>

	- <para><?xxe-sn 2ahi4rjnvuo 25?>To sum it up, context consists of two
	- complements parts: on the one hand <emphasis><?xxe-sn 2axopn9e3uo 15?>static(early)
	- context</emphasis>, that denotes compile time inference's result and on
	- the other hand, <emphasis><?xxe-sn 2axopn9e3uo 16?>late(dynamic)
	- context</emphasis> denotes annotations decided upon at runtime.</para>
	+ <para><?xxe-sn 2ahi4rjnvuo 25?>Function <code><?xxe-sn 2fq6kae5o8w 1?>executeComputation</code>
	+ is used in different contexts in scopes <code><?xxe-sn 2fq6kae5o8w 4?>scopeA</code>,
	+ <code><?xxe-sn 2fq6kae5o8w 5?>scopeB</code>, thus it is impossible to
	+ infer statically which <code><?xxe-sn 2fq6kae5o8w 2?>compute</code> 's
	+ specialisation it should invoke. In this case <code><?xxe-sn 2fq6kae5o8w 3?>executeComputation</code>
	+ function's signature is expanded to take in a hidden late parameter with
	+ its value conveying an actual context in order to dynamically invoke an
	+ appropriate specialization at run time.</para>
	</section>
	</chapter>
	diff --git a/documentation/Syntax/syntax.xml b/documentation/Syntax/syntax.xml
	index c079908..9d47543 100644
	--- a/documentation/Syntax/syntax.xml
	+++ b/documentation/Syntax/syntax.xml
	@@ -1,1232 +1,1290 @@
	<?xml version="1.0" encoding="UTF-8"?>
	<chapter version="5.1" xmlns="http://docbook.org/ns/docbook"
	xmlns:xlink="http://www.w3.org/1999/xlink"
	xmlns:xila="http://www.w3.org/2001/XInclude/local-attributes"
	xmlns:xi="http://www.w3.org/2001/XInclude"
	xmlns:trans="http://docbook.org/ns/transclusion"
	xmlns:svg="http://www.w3.org/2000/svg"
	xmlns:m="http://www.w3.org/1998/Math/MathML"
	xmlns:html="http://www.w3.org/1999/xhtml"
	xmlns:db="http://docbook.org/ns/docbook">
	<?xxe-sn 26yv439af40 59?>

	<title><?xxe-sn 26yv439af40 5a?>Syntax</title>

	<para><?xxe-sn 26yv439af40 5v?>There is a number of principles the Xreate
	syntax is based on:</para>

	<itemizedlist>
	<?xxe-sn 26yv439af40 5w?>

	<listitem>
	<?xxe-sn 26yv439af40 5x?>

	<para><?xxe-sn 26yv439af40 5y?>Follows SSA(single assignment) form: each
	identifier is defined only once and no redefinitions allowed.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26yv439af40 5z?>

	<para><?xxe-sn 26yv439af40 60?>Follows literate programming principles
	where possible. For example, identifiers can be defined in any order
	reflecting personal preferences and convenience for a developer.
	Regardless of the definition order, expressions are computed based on
	dependencies between them. Literate programming principles from a
	practical point of view simplify code testing, support, catching
	regressions, etc.</para>
	</listitem>
	</itemizedlist>

	<section>
	<?xxe-sn 26yv439af40 61?>

	<title><?xxe-sn 26yv439af40 62?>Literals and Expressions</title>

	<para><?xxe-sn 26yv439af40 63?>Xreate expressions have a form:</para>

	<synopsis><?xxe-sn 26yv439af40 64?>SYNTAX:
	//expression// [:: //type//; //annotations-list// ]</synopsis>

	<itemizedlist>
	<?xxe-sn 26yv439af40 fd?>

	<listitem>
	<?xxe-sn 26yv439af40 fe?>

	<para><?xxe-sn 26yv439af40 ff?><emphasis><?xxe-sn 26yv439af40 fg?>annotation-list</emphasis>
	is a list of annotations delimited by semicolon.</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 26yv439af40 67?>Expressions consist of literals and various
	operations as follows:</para>

	<informaltable>
	<?xxe-sn 26yv439af40 68?>

	<tgroup cols="2">
	<?xxe-sn 26yv439af40 69?>

	<colspec colwidth="115*"><?xxe-sn 26yv439af40 6a?></colspec>

	<colspec colwidth="885*"><?xxe-sn 26yv439af40 6b?></colspec>

	<tbody>
	<?xxe-sn 26yv439af40 6c?>

	<row>
	<?xxe-sn 26yv439af40 6d?>

	<entry><?xxe-sn 26yv439af40 6e?>Literals</entry>

	<entry><?xxe-sn 26yv439af40 6f?>numbers, strings: <code><?xxe-sn 2ese8ot7ke8 e?>5</code>,
	<code><?xxe-sn 2ese8ot7ke8 f?>"Nimefurahi kukujua"</code>.</entry>
	</row>

	<row>
	<?xxe-sn 26yv439af40 6h?>

	<entry><?xxe-sn 26yv439af40 6i?>Lists, records</entry>

	<entry><?xxe-sn 26yv439af40 6j?><emphasis><?xxe-sn 2ese8ot7ke8 c?>Record</emphasis>
	is a collection of elements of different types - <code><?xxe-sn 26yv439af40 6k?>{year = 1934, month = "april"}</code>.
	<emphasis><?xxe-sn 2ese8ot7ke8 d?>List</emphasis> is a collection
	of elements of the same type without keys - <code><?xxe-sn 26yv439af40 6l?>{16, 8, 3}</code>.
	Range is a specific form of a list - <code><?xxe-sn 2apiasqubk0 4?>[1..18]</code>.</entry>
	</row>

	<row>
	<?xxe-sn 26yv439af40 6m?>

	<entry><?xxe-sn 26yv439af40 6n?>Arithmetic operations</entry>

	<entry><?xxe-sn 26yv439af40 6o?>Basic arithmetic operations:
	<code><?xxe-sn 2ese8ot7ke8 g?>+</code>, <code><?xxe-sn 2ese8ot7ke8 h?>-</code>,
	<code><?xxe-sn 2ese8ot7ke8 i?>*</code>, <code><?xxe-sn 2ese8ot7ke8 j?>/</code>.</entry>
	</row>

	<row>
	<?xxe-sn 2evpzktyvg7 -wunr7fl0rw8j?>

	<entry><?xxe-sn 2evpzktyvg7 -wunr7fl0rw8i?>Boolean
	operations</entry>

	<entry><?xxe-sn 2evpzktyvg7 -wunr7fl0rw8h?>Negation example:
	<code><?xxe-sn 2evpzktyvg7 -wunr7fl0rw8g?>-isEmty()</code>.</entry>
	</row>

	<row>
	<?xxe-sn 26yv439af40 6q?>

	<entry><?xxe-sn 26yv439af40 6r?>Relations</entry>

	<entry><?xxe-sn 26yv439af40 6s?><code><?xxe-sn 2ese8ot7ke8 r?>==</code>,
	<code><?xxe-sn 2ese8ot7ke8 s?>!=</code>, <code><?xxe-sn 2ese8ot7ke8 t?><></code>,
	<code><?xxe-sn 2ese8ot7ke8 u?><</code>, <code><?xxe-sn 2ese8ot7ke8 v?><=</code>,
	<code><?xxe-sn 2ese8ot7ke8 w?>></code>, <code><?xxe-sn 2ese8ot7ke8 x?>>=</code>.
	Both <code><?xxe-sn 2ese8ot7ke8 y?>!=</code>, <code><?xxe-sn 2ese8ot7ke8 z?><></code>
	mean <emphasis><?xxe-sn 26yv439af40 6v?>not equal</emphasis>
	relation. Examples: <code><?xxe-sn 2ese8ot7ke8 10?>8>=3</code>,
	<code><?xxe-sn 2ese8ot7ke8 11?>"Blue" <> "Green"</code>.</entry>
	</row>

	<row>
	<?xxe-sn 26yv439af40 6x?>

	<entry><?xxe-sn 26yv439af40 6y?>List and record operations</entry>

	<entry><?xxe-sn 26yv439af40 6z?>The <emphasis><?xxe-sn 26yv439af40 70?>index</emphasis>
	operation to access individual elements of a list or record.
	Example: <code><?xxe-sn 2ese8ot7ke8 12?>colors = {"Green", "Blue"}::[string]. color = colors[0]:: string.</code>
	Accesing a record's element: <code><?xxe-sn 2ese8ot7ke8 13?>date = {year = 1934, month = "april"}. year = date["year"].</code></entry>
	</row>

	<row>
	<?xxe-sn 26yv439af40 73?>

	<entry><?xxe-sn 26yv439af40 74?>Identifiers</entry>

	<entry><?xxe-sn 26yv439af40 75?>Example: <code><?xxe-sn 26yv439af40 76?>a - b</code></entry>
	</row>

	<row>
	<?xxe-sn 26yv439af40 77?>

	<entry><?xxe-sn 26yv439af40 78?>Functions</entry>

	<entry><?xxe-sn 26yv439af40 79?>Example: <code><?xxe-sn 26yv439af40 7a?>result = isOdd(6):: bool.</code></entry>
	</row>
	</tbody>
	</tgroup>
	</informaltable>
	</section>

	<section>
	<?xxe-sn 2evpzktyvg7 -wunr7fl0rw8v?>

	<title><?xxe-sn 2evpzktyvg7 -wunr7fl0rw8u?>Annotations</title>

	<para><?xxe-sn 2evpzktyvg7 -wunr7fl0rw8t?>This chapter is about Brute
	syntax. See <link xlink:href="/d/transcend/"><?xxe-sn 2evpzktyvg7 -wunr7fl0rw8l?>Transcend</link>
	for details regarding Transcend and annotations syntax.</para>
	</section>

	<section>
	<?xxe-sn 26yv439af40 7b?>

	<title><?xxe-sn 26yv439af40 7c?>Code Blocks</title>

	<para><?xxe-sn 26yv439af40 7d?>Code block is a list of expressions
	delimited by a period. It has a <emphasis><?xxe-sn 26yv439af40 7e?>body</emphasis>
	- the main expression along with optional identifiers' definitions.</para>

	<synopsis><?xxe-sn 26yv439af40 7f?>SYNTAX:
	{
	[//ident// = //expression//. \| //body-expression//. ]..
	}</synopsis>

	<para><?xxe-sn 26yv439af40 7g?>Code blocks consist of <emphasis><?xxe-sn 26yv439af40 7h?>a
	body expression</emphasis> and an optional set of assignments to define
	identifiers used in the body expression. A code block's computation result
	is defined as a result of computing its body expression. Identifiers are
	computed before expressions they are appear in, regardless of a
	definitions' order.</para>

	<programlisting xml:id="CodeBlocks1"><?xxe-sn 26yv439af40 7i?>name="tests/ast.cpp: AST.Doc_CodeBlocks1"
	test = function:: int; entry
	{
	a + b:: int

	a = 10:: int.
	b = 2:: int.
	}</programlisting>

	<para><?xxe-sn 26yv439af40 7j?>Above is an example of the code block with
	<code><?xxe-sn 26yv439af40 7k?>a+b</code> as its body expression(because
	it does not have a form of an assignment). In this case the body depends
	on the identifiers <code><?xxe-sn 26yv439af40 7l?>a</code>,
	<code><?xxe-sn 26yv439af40 7m?>b</code> so the compiler computes both of
	them beforehand.</para>

	<para><?xxe-sn 26yv439af40 7n?>A computation order depends only on
	dependencies between expressions. This approach has properties as
	follows:</para>

	<itemizedlist>
	<?xxe-sn 26yv439af40 7o?>

	<listitem>
	<?xxe-sn 26yv439af40 7p?>

	<para><?xxe-sn 26yv439af40 7q?>Mutually independent identifiers can be
	evaluated in any order.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26yv439af40 7r?>

	<para><?xxe-sn 26yv439af40 7s?>An identifier computed only if it is
	required(at least transitively) by a code block's body
	expression.</para>
	</listitem>
	</itemizedlist>
	</section>

	<section>
	<?xxe-sn 26yv439af40 7t?>

	<title><?xxe-sn 26yv439af40 7u?>Functions</title>

	<synopsis><?xxe-sn 26yv439af40 7v?>SYNTAX:
	//function-name// = function ([//argument//:: //type//[; //annotation-list//]]...):: //return-type// [; //annotations//]...
	//function-block//</synopsis>

	<itemizedlist>
	<?xxe-sn 26yv439af40 7w?>

	<listitem>
	<?xxe-sn 26yv439af40 7x?>

	<para><?xxe-sn 26yv439af40 7y?><emphasis><?xxe-sn 26yv439af40 7z?>function-name</emphasis>
	Name of a function.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26yv439af40 80?>

	<para><?xxe-sn 26yv439af40 81?><emphasis><?xxe-sn 26yv439af40 82?>argument</emphasis>
	Formal parameters. Arguments are delimited by comma.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26yv439af40 83?>

	<para><?xxe-sn 26yv439af40 84?><emphasis><?xxe-sn 26yv439af40 85?>type</emphasis>,
	<emphasis><?xxe-sn 26yv439af40 86?>return-type</emphasis> Formal
	parameter's and returning value's types.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26yv439af40 87?>

	<para><?xxe-sn 26yv439af40 88?><emphasis><?xxe-sn 26yv439af40 89?>function-block</emphasis>
	Code block that acts as a function's definition.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26yv439af40 8a?>

	<para><?xxe-sn 26yv439af40 8b?><emphasis><?xxe-sn 26yv439af40 8c?>annotations</emphasis>
	List of annotations delimited by semicolon.</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 26yv439af40 8d?>Below is an example of the function
	<code><?xxe-sn 26yv439af40 8e?>sum</code> returning sum of its two
	arguments. Moreover there are several annotations defined. First
	annotation <code><?xxe-sn 26yv439af40 8f?>entry</code> has a special
	meaning — it depicts an entry point or a main function in a program.
	Second annotation <code><?xxe-sn 26yv439af40 8g?>status(needs_review)</code>
	is a demonstration that developers can annotate functions using custom
	annotations to express related intentions or properties.</para>

	<programlisting xml:id="Functions1"><?xxe-sn 26yv439af40 8h?>name="tests/ast.cpp: AST.Doc_Functions1"
	sum = function(x:: int, y:: int):: int; entry; status(needs_review)
	{
	x + y
	}</programlisting>
	</section>

	<section>
	<?xxe-sn 26yv439af40 8i?>

	<title><?xxe-sn 26yv439af40 8j?>Function Specializations</title>

	<synopsis><?xxe-sn 26yv439af40 8k?>SYNTAX:
	guard:: //annotation//
	{
	//functions-list//
	}</synopsis>

	<itemizedlist>
	<?xxe-sn 26yv439af40 8l?>

	<listitem>
	<?xxe-sn 26yv439af40 8m?>

	<para><?xxe-sn 26yv439af40 8n?><emphasis><?xxe-sn 26yv439af40 8o?>annotation</emphasis>
	Guard expressed in the form of an annotation.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26yv439af40 8p?>

	<para><?xxe-sn 26yv439af40 8q?><emphasis><?xxe-sn 26yv439af40 8r?>functions-list</emphasis>
	One or more functions that share the same guard.</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 26yv439af40 8s?>Specializations is a crucial Xreate concept
	serving as the principal connection between Transcend and Brute levels.
	Xreate allows several functions to share the same name; in this case they
	are called <emphasis><?xxe-sn 26yv439af40 fk?> specializations</emphasis>.
	This is a syntactic foundation for <emphasis><?xxe-sn 26yv439af40 8u?>function
	level <link xlink:href="/d/concepts/polymorphism/"><?xxe-sn 2evpzktyvg7 -wunr7fl0rw8k?>polymorphism</link></emphasis>,
	i.e. ability for the compiler to decide which exactly function is called
	out of several available options. The polymorphism resolution can happen
	during compilation(early polymorphism) or at run-time(late
	polymorphism).</para>

	<para><?xxe-sn 26yv439af40 8v?>Functions with the same name, i.e.
	different specializations must have identifiers called <emphasis><?xxe-sn 26yv439af40 8w?>guards</emphasis>
	to uniquely define a specialization. In this sense, a shared name is just
	a placeholder, which only along with a guard comprise the fully qualified
	exact function identifier. On the Brute level it is possible to specify
	only a function's shared name for invocation. On the other hand, Transcend
	is responsible to supply a guard part. When a function is actually called
	by its name in a program it's expected that the resolution is already done
	by Transcend at some time earlier and it supplies the correct guard to
	uniquely specify which exactly specialization to call. This gives
	Transcend a deep control over an actual program behaviour.</para>

	<para><?xxe-sn 26yv439af40 8x?>An example:</para>

	<programlisting xml:id="FunctionSpecialization1"><?xxe-sn 26yv439af40 8y?>name="tests/ast.cpp: AST.Doc_FunctionSpecializations1", lines=15
	guard:: safe_enviroment
	{
	sum = function (a::int, b::int):: int
	{
	result = a + b:: int.

	if (-isLastOpOverflow(result)):: int
	{
	result
	}
	else
	{
	overflowErrorCode()
	}
	}
	}

	guard:: fast_enviroment
	{
	sum = function (a::int, b::int) :: int
	{
	a + b
	}
	}</programlisting>

	<para><?xxe-sn 2evpzktyvg7 -wunr7fl0rw8f?>To alter existing code behaviour
	it's always possible to add new specializations and adjust Transcend rules
	to specify situations when a new specialization should(or should not) be
	used.</para>

	<note>
	<?xxe-sn 26yv439af40 8z?>

	<para><?xxe-sn 26yv439af40 90?>See <link
	xlink:href="/d/transcend/ast-api/#function-s-specializatio"><?xxe-sn 26yv439af40 91?>API</link>
	to get more detailed information on how guards are processed on the
	Transcend side.</para>
	</note>
	</section>

	<section>
	<?xxe-sn 26yv439af40 92?>

	<title><?xxe-sn 26yv439af40 93?>Branch Statements</title>

	<section>
	<?xxe-sn 26yv439af40 94?>

	<title><?xxe-sn 26yv439af40 95?>IF Statement</title>

	<synopsis><?xxe-sn 26yv439af40 96?>SYNTAX:
	if ( //condition// ):: //type// [; //annotations// ]..
	//block-true//
	else
	//block-false//</synopsis>

	<para><?xxe-sn 26yv439af40 97?>The <code><?xxe-sn 26yv439af40 fh?>if</code>
	statement executes <emphasis><?xxe-sn 26yv439af40 98?>block-true</emphasis>
	or <emphasis><?xxe-sn 26yv439af40 99?>block-false</emphasis> depending
	on the <emphasis><?xxe-sn 26yv439af40 9a?>condition</emphasis>
	evaluation's result.</para>

	<para><?xxe-sn 26yv439af40 9b?>Example:</para>

	<programlisting xml:id="IfStatement1"><?xxe-sn 26yv439af40 9c?>name="tests/ast.cpp: AST.Doc_BranchStatements"
	answer = if (question == "Favorite color?"):: string
	{"Yellow"} else {"Don't know"}.</programlisting>
	</section>

	<section>
	<?xxe-sn 26yv439af40 9d?>

	<title><?xxe-sn 26yv439af40 9e?>SWITCH Statement</title>

	<synopsis><?xxe-sn 26yv439af40 9f?>SYNTAX:
	switch ( //condition// ) :: //type// [; //annotations//]..
	[case ( //guard// ) code-block]..
	case default //default-code-block//
	</synopsis>

	<itemizedlist>
	<?xxe-sn 26yv439af40 9g?>

	<listitem>
	<?xxe-sn 26yv439af40 9h?>

	<para><?xxe-sn 26yv439af40 9i?><emphasis><?xxe-sn 26yv439af40 9j?>condition</emphasis>
	Expression to to decide which branch to execute next.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26yv439af40 9k?>

	<para><?xxe-sn 26yv439af40 9l?><emphasis><?xxe-sn 26yv439af40 9m?>guard</emphasis>
	Value to match against <emphasis><?xxe-sn 26yv439af40 9n?>condition.</emphasis></para>
	</listitem>

	<listitem>
	<?xxe-sn 26yv439af40 9o?>

	<para><?xxe-sn 26yv439af40 9p?><emphasis><?xxe-sn 26yv439af40 9q?>default-code-block</emphasis>
	Executed if no appropriate case found.</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 26yv439af40 9r?>The <code><?xxe-sn 2evpzktyvg7 -wunr7fl0rw8e?>switch</code>
	statement evaluation's result is that of the branch whose
	<emphasis><?xxe-sn 26yv439af40 9s?>guard</emphasis> matches the
	<emphasis><?xxe-sn 26yv439af40 9t?>condition</emphasis>.</para>

	<para><?xxe-sn 26yv439af40 9u?>An example:</para>

	<programlisting xml:id="SwitchStatement1"><?xxe-sn 26yv439af40 9v?>name="tests/ast.cpp: AST.Doc_BranchStatements"
	monthName = switch(monthNum) :: string
	case (1) {"Jan"}
	case (2) {"Feb"}
	case default {"It's strange..an unexpected month"}.</programlisting>
	</section>
	</section>

	<section>
	<?xxe-sn 26yv439af40 9w?>

	<title><?xxe-sn 26yv439af40 9x?>Loops</title>

	<para><?xxe-sn 2evpzktyvg7 -wunr7fl0rw8d?>Xreate loops are constructed in
	such a way that they hide actually mutable operations semantic under an
	immutable facade compatible with a single assignment form.</para>

	<section>
	<?xxe-sn 26yv439af40 9y?>

	<title><?xxe-sn 26yv439af40 9z?>LOOP Statement</title>

	<synopsis><?xxe-sn 26yv439af40 a0?>SYNTAX:
	loop ( //init-value// -> //accumulator// ):: //type// [; //annotations//] //loop-body//</synopsis>

	<itemizedlist>
	<?xxe-sn 26yv439af40 a1?>

	<listitem>
	<?xxe-sn 26yv439af40 a2?>

	<para><?xxe-sn 26yv439af40 a3?><emphasis><?xxe-sn 26yv439af40 a4?>init-value</emphasis>
	Initial value a loop starts from.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26yv439af40 a5?>

	<para><?xxe-sn 26yv439af40 a6?><emphasis><?xxe-sn 26yv439af40 a7?>accumulator</emphasis>
	Identifier which holds loop's result after each iteration.</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 26yv439af40 a8?>For each iteration <emphasis><?xxe-sn 26yv439af40 a9?>accumulator</emphasis>
	assumes the result of a previous iteration or <emphasis><?xxe-sn 26yv439af40 aa?>init-value</emphasis>
	for the first iteration. The result of <emphasis><?xxe-sn 26yv439af40 ab?>loop-body</emphasis>
	evaluation is used as a <emphasis><?xxe-sn 26yv439af40 ac?>accumulator</emphasis>'s
	next iteration value and as an overall loop statement result after the
	last iteration.</para>

	<para><?xxe-sn 26yv439af40 ad?>Note, that this notation does not have an
	explicit termination condition! The compiler relies on the loop body's
	fixed point in order to decide when to interrupt the loop. Consider an
	example:</para>

	<programlisting xml:id="LoopStatement1"><?xxe-sn 26yv439af40 ae?>COUNTEREXAMPLE, name="tests/ast.cpp: AST.Doc_LoopStatements"
	//an infinite loop
	answer = loop (2 -> x) :: int
	{
	if(IsPerfect(x)):: int {x} else {x+1}
	}.</programlisting>

	<para><?xxe-sn 26yv439af40 af?>The example tests numbers for being
	perfect(sum of all proper divisors equals to the number itself). During
	iterations the accumulator <code><?xxe-sn 26yv439af40 ag?>x</code>
	assumes values as follows: 2, 3, 4, 5, 6, 6... After the first perfect
	number is found, no further iteration will change the result anymore
	since there is no increment, so the loop continues to go through the
	same number again and again, making this an infinite loop. Obviously,
	<code><?xxe-sn 26yv439af40 ah?>x=6</code>(the first perfect number) is a
	fixed point in this example. It does not make any sense to continue
	going through further iterations once a fixed point is reached because
	the result is not going to be changed anymore, thus the loop can be
	safely interrupted at this point.</para>

	<para><?xxe-sn 26yv439af40 ai?>The compiler relies on manually provided
	annotations to recognize when a fixed point is reached. There is a
	special annotation <code><?xxe-sn 26yv439af40 aj?>final</code> reserved
	to specify a fixed point for loops. Once an expression that marked as
	<code><?xxe-sn 26yv439af40 ak?>final</code> gets evaluated it's assumed
	that a fixed point is reached or in words the compiler knows it's the
	very last iteration after which loop can be terminated safely. The
	correct code for the example above is:</para>

	<programlisting xml:id="LoopStatement2"><?xxe-sn 26yv439af40 al?>name="tests/ast.cpp: AST.Doc_LoopStatements"
	//a loop exits after the first perfect number is found
	answer2 = loop (2->x) :: int
	{
	if(IsPerfect(x))::int {x:: int; final} else {x+1}
	}.</programlisting>

	<para><?xxe-sn 26yv439af40 am?>In this case the compiler is able to
	recognize that a fixed point is reached in order to know when it is safe
	to terminate the loop. In the example, the final result <code><?xxe-sn 26yv439af40 an?>answer2</code>
	is <code><?xxe-sn 26yv439af40 ao?>6</code>.</para>
	</section>

	<section>
	<?xxe-sn 26yv439af40 ap?>

	<title><?xxe-sn 26yv439af40 aq?>LOOP FOLD Statement</title>

	<synopsis><?xxe-sn 26yv439af40 ar?>SYNTAX:
	loop fold ( //list// -> //element//:: //type// [; //annotations//], //init-value// -> //accumulator//):: //type// [; //annotations//]
	//loop-body//</synopsis>

	<itemizedlist>
	<?xxe-sn 26yv439af40 as?>

	<listitem>
	<?xxe-sn 26yv439af40 at?>

	<para><?xxe-sn 26yv439af40 au?><emphasis><?xxe-sn 26yv439af40 av?>list</emphasis>
	Container to iterate over.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26yv439af40 aw?>

	<para><?xxe-sn 26yv439af40 ax?><emphasis><?xxe-sn 26yv439af40 ay?>element</emphasis>
	Identifier that assumes value of a currently processing list
	element.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26yv439af40 az?>

	<para><?xxe-sn 26yv439af40 b0?><emphasis><?xxe-sn 26yv439af40 b1?>type</emphasis>,
	<emphasis><?xxe-sn 26yv439af40 b2?>annotations</emphasis> Expression
	types and optional annotations delimited by semicolon.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26yv439af40 b3?>

	<para><?xxe-sn 26yv439af40 b4?><emphasis><?xxe-sn 26yv439af40 b5?>init-value</emphasis>
	Accumulator's initial value loop starts from.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26yv439af40 b6?>

	<para><?xxe-sn 26yv439af40 b7?><emphasis><?xxe-sn 26yv439af40 b8?>accumulator</emphasis>
	Identifier that assumes loop-body evaluation result after each
	iteration.</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 26yv439af40 b9?>The <code><?xxe-sn 2evpzktyvg7 -wunr7fl0rw87?>loop fold</code>
	statement is a commonly used particular instance of <code><?xxe-sn 2evpzktyvg7 -wunr7fl0rw85?>loop</code>
	to Iterate over <emphasis><?xxe-sn 26yv439af40 ba?>list</emphasis> in
	order to accumulate the result by applying the <emphasis><?xxe-sn 26yv439af40 bb?>loop-body</emphasis>
	transformation to each <emphasis><?xxe-sn 26yv439af40 bc?>element</emphasis>
	and an intermediate <emphasis><?xxe-sn 26yv439af40 bd?>accumulator</emphasis>.
	The result of a current iteration is used as the <emphasis><?xxe-sn 2evpzktyvg7 -wunr7fl0rw8b?>accumulator</emphasis>
	value for a next iteration. Accordingly, the overall loop value equals
	that of <emphasis><?xxe-sn 2evpzktyvg7 -wunr7fl0rw8c?>accumulator</emphasis>
	after the last iteration. If a fixed point is found evaluation
	terminates earlier.</para>

	<para><?xxe-sn 26yv439af40 be?>Example shows a code excerpt that looks
	for the minimal element in a given list(and less then the initial value
	<code><?xxe-sn 26yv439af40 bf?>10</code>):</para>

	<programlisting xml:id="FoldStatement1"><?xxe-sn 26yv439af40 bg?>name="tests/ast.cpp: AST.Doc_LoopStatements"
	numbers = {4, 8, 7, 1, 5}:: [int].
	min = loop fold(numbers->x:: int, 10->acc):: int
	{
	if (acc > x):: int {x} else {acc}
	}.</programlisting>
	</section>

	<section>
	<?xxe-sn 26yv439af40 bh?>

	<title><?xxe-sn 26yv439af40 bi?>LOOP MAP Statement</title>

	<synopsis><?xxe-sn 26yv439af40 bj?>SYNTAX:
	loop map (//list// -> //element// :: //type// [; //annotations// ] ) :: //type// [; //annotations// ]
	//loop-body//</synopsis>

	<itemizedlist>
	<?xxe-sn 26yv439af40 bk?>

	<listitem>
	<?xxe-sn 26yv439af40 bl?>

	<para><?xxe-sn 26yv439af40 bm?><emphasis><?xxe-sn 26yv439af40 bn?>list</emphasis>
	Container to iterate over.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26yv439af40 bo?>

	<para><?xxe-sn 26yv439af40 bp?><emphasis><?xxe-sn 26yv439af40 bq?>element</emphasis>
	Identifier that assumes value of a currently processed list
	element.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26yv439af40 br?>

	<para><?xxe-sn 26yv439af40 bs?><emphasis><?xxe-sn 26yv439af40 bt?>type</emphasis>,
	<emphasis><?xxe-sn 26yv439af40 bu?>annotations</emphasis> Type and
	optional annotations delimited by semicolon.</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 26yv439af40 by?>The <code><?xxe-sn 2evpzktyvg7 -wunr7fl0rw84?>loop fold</code>
	statement is a commonly used particular instance of <code><?xxe-sn 2evpzktyvg7 -wunr7fl0rw83?>loop</code>
	to Iterate over <emphasis><?xxe-sn 26yv439af40 bz?>list</emphasis> and
	applying the <emphasis><?xxe-sn 26yv439af40 c0?>loop-body</emphasis>
	transformation to each element. The result is a list that consists of
	all the transformed elements.</para>

	<para><?xxe-sn 2evpzktyvg7 -wunr7fl0rw8a?>An example below demonstrates
	creating the <code><?xxe-sn 2evpzktyvg7 -wunr7fl0rw89?>even_number</code>
	list by multiplying by 2 every element of <code><?xxe-sn 2evpzktyvg7 -wunr7fl0rw88?>odd_numbers</code>:</para>

	<programlisting xml:id="MapStatement1"><?xxe-sn 26yv439af40 c1?>name="tests/ast.cpp: AST.Doc_LoopStatements"
	odd_numbers = {1, 3, 5}:: [int].
	even_numbers = loop map(odd_numbers -> number:: int) :: [int]
	{ 2 * number }.</programlisting>
	</section>
	</section>

	<section>
	<?xxe-sn 26yv439af40 c5?>

	<title><?xxe-sn 26yv439af40 c6?>Types</title>

	<para><?xxe-sn 26yv439af40 c7?>Primitive Types:</para>

	<informaltable>
	<?xxe-sn 26yv439af40 c8?>

	<tgroup cols="2">
	<?xxe-sn 26yv439af40 c9?>

	<colspec colwidth="173*"><?xxe-sn 26yv439af40 ca?></colspec>

	<colspec colwidth="827*"><?xxe-sn 26yv439af40 cb?></colspec>

	<tbody>
	<?xxe-sn 26yv439af40 cc?>

	<row>
	<?xxe-sn 2ey6qxf8um8 1?>

	<entry><?xxe-sn 2ey6qxf8um8 2?><code><?xxe-sn 2ey6qxf8um8 7?>bool</code></entry>

	<entry><?xxe-sn 2ey6qxf8um8 8?>Booleans.</entry>
	</row>

	<row>
	<?xxe-sn 2ey6qxf8um8 3?>

	<entry><?xxe-sn 2ey6qxf8um8 4?><code><?xxe-sn 2ey6qxf8um8 9?>i8</code>,
	<code><?xxe-sn 2ey6qxf8um8 a?>i32</code>, <code><?xxe-sn 2ey6qxf8um8 b?>i64</code></entry>

	<entry><?xxe-sn 2ey6qxf8um8 c?>Signed integers; 8, 32, 64 bit wide
	respectively.</entry>
	</row>

	<row>
	<?xxe-sn 2ey6qxf8um8 5?>

	<entry><?xxe-sn 2ey6qxf8um8 6?><code><?xxe-sn 2ey6qxf8um8 f?>int</code>,
	<code><?xxe-sn 2ey6qxf8um8 g?>num</code></entry>

	<entry><?xxe-sn 2ey6qxf8um8 d?>Currently <code><?xxe-sn 2ey6qxf8um8 e?>i32</code>
	aliases. Reserved as placeholders for an auto detected appropriate
	integral type and for auto detected appropriate either integral of
	floating-point type, respectively.</entry>
	</row>

	<row>
	<?xxe-sn 26yv439af40 ci?>

	<entry><?xxe-sn 26yv439af40 cj?><code><?xxe-sn 26yv439af40 ck?>float</code></entry>

	<entry><?xxe-sn 26yv439af40 cl?>Double precision floating-point
	numbers.</entry>
	</row>

	<row>
	<?xxe-sn 26yv439af40 cz?>

	<entry><?xxe-sn 26yv439af40 d0?><code><?xxe-sn 26yv439af40 d1?>string</code></entry>

	<entry><?xxe-sn 26yv439af40 d2?>Currently null terminated ANSI
	char string. Reserved to be generic type with no particular
	implementation. A concrete implementation is to be determined
	similarly to the <link
	xlink:href="/d/concepts/containers/"><?xxe-sn 2ey6qxf8um8 h?>containers</link>
	approach.</entry>
	</row>

	<row>
	<?xxe-sn 26yv439af40 d3?>

	<entry><?xxe-sn 26yv439af40 d4?><code><?xxe-sn 26yv439af40 d5?>*</code></entry>

	<entry><?xxe-sn 26yv439af40 d6?>An unspecified type. Postpones
	type checks for this expression. Examples: <code><?xxe-sn 26yv439af40 d7?>x = {amount=200, currency="USD"}::*.</code></entry>
	</row>
	</tbody>
	</tgroup>
	</informaltable>

	<para><?xxe-sn 26yv439af40 d8?>Compound types:</para>

	<informaltable>
	<?xxe-sn 26yv439af40 d9?>

	<tgroup cols="2">
	<?xxe-sn 26yv439af40 da?>

	<colspec colwidth="312*"><?xxe-sn 26yv439af40 db?></colspec>

	<colspec colwidth="688*"><?xxe-sn 26yv439af40 dc?></colspec>

	<tbody>
	<?xxe-sn 26yv439af40 dd?>

	<row>
	<?xxe-sn 26yv439af40 de?>

	<entry><?xxe-sn 26yv439af40 df?>[ <emphasis><?xxe-sn 2ey6qxf8um8 j?>element-type</emphasis> ]</entry>

	<entry><?xxe-sn 26yv439af40 di?>List of elements of the same type
	<emphasis><?xxe-sn 26yv439af40 dj?>element-type</emphasis>.
	Examples: <code><?xxe-sn 26yv439af40 dk?>x = {1, 2, 3}:: [int]</code>
	- list of <code><?xxe-sn 26yv439af40 dl?>int</code>'s. Lists can
	have different internal implementations.</entry>
	</row>

	<row>
	<?xxe-sn 26yv439af40 dm?>

	<entry><?xxe-sn 26yv439af40 dn?>{<emphasis><?xxe-sn 2ey6qxf8um8 k?> key</emphasis>:: <emphasis><?xxe-sn 2ey6qxf8um8 l?>type</emphasis>, ... }</entry>

	<entry><?xxe-sn 26yv439af40 dr?>Record: a list of elements of
	different types possibly with named keys. Examples:
	<code><?xxe-sn 2ey6qxf8um8 15?>{int, string}</code>,
	<code><?xxe-sn 2ey6qxf8um8 16?>{name::string, age::int}</code>.</entry>
	</row>

	<row>
	<?xxe-sn 26yv439af40 du?>

	<entry><?xxe-sn 26yv439af40 dv?>variant {<emphasis><?xxe-sn 2ey6qxf8um8 m?>option</emphasis> :: {<emphasis><?xxe-sn 2ey6qxf8um8 n?>type</emphasis>, ...}, ...}</entry>

	<entry><?xxe-sn 26yv439af40 dz?>ADT type. Variables of this type
	can hold value of any type out of a list of permitted ones.
	Examples: <code><?xxe-sn 26yv439af40 e0?>variant {FullAddress:: {string, string, string}, ShortAddress:: {string}}</code>.</entry>
	</row>

	<row>
	<?xxe-sn 26yv439af40 e1?>

	<entry><?xxe-sn 26yv439af40 e2?>slave <emphasis><?xxe-sn 2ey6qxf8um8 o?>identifier</emphasis></entry>

	<entry><?xxe-sn 26yv439af40 e5?>Denotes a type constructed by
	Transcend. See <link xlink:href="#slave-types"><?xxe-sn 2ezs03nkiyo 17?>slave
	types</link>. An example: <code><?xxe-sn 26yv439af40 e6?>slave unit_test</code>.</entry>
	</row>
	</tbody>
	</tgroup>
	</informaltable>

	<para><?xxe-sn 2ey6qxf8um8 p?>Type operations:</para>

	<informaltable>
	<?xxe-sn 2ey6qxf8um8 q?>

	<tgroup cols="2">
	<?xxe-sn 2ey6qxf8um8 r?>

	<colspec colwidth="115*"><?xxe-sn 2ey6qxf8um8 17?></colspec>

	<colspec colwidth="885*"><?xxe-sn 2ey6qxf8um8 18?></colspec>

	<tbody>
	<?xxe-sn 2ey6qxf8um8 s?>

	<row>
	<?xxe-sn 2ey6qxf8um8 t?>

	<entry><?xxe-sn 2ey6qxf8um8 u?><emphasis><?xxe-sn 2ey6qxf8um8 v?>type</emphasis> [ <emphasis><?xxe-sn 2ey6qxf8um8 w?>key</emphasis> ]</entry>

	<entry><?xxe-sn 2ey6qxf8um8 x?>Index operation: accessing elements
	of a compound type. Examples: <code><?xxe-sn 2ey6qxf8um8 y?>Bio = type {birth_year:: int, name:: string}. YearBirth = type Bio[birth_year].</code></entry>
	</row>

	<row>
	<?xxe-sn 2ey6qxf8um8 z?>

	<entry><?xxe-sn 2ey6qxf8um8 10?><emphasis><?xxe-sn 2ey6qxf8um8 12?>type</emphasis> ( <emphasis><?xxe-sn 2ey6qxf8um8 13?>parameters</emphasis>... )</entry>

	<entry><?xxe-sn 2ey6qxf8um8 11?>Constructs a concrete type with
	the given parameters. Examples: <code><?xxe-sn 2ey6qxf8um8 14?>MyTree = type Tree(int)</code>.</entry>
	</row>
	</tbody>
	</tgroup>
	</informaltable>

	<para><?xxe-sn 26yv439af40 ee?>New types are defined as follows:</para>

	<synopsis><?xxe-sn 26yv439af40 ef?>SYNTAX:
	//type-name// = type (//parameters//...) //type-definition// .</synopsis>

	<para><?xxe-sn 26yv439af40 eg?>Examples:</para>

	<programlisting xml:id="Types1"><?xxe-sn 26yv439af40 eh?>name="tests/ast.cpp: AST.Doc_Types"
	Tuple = type {string, int}.
	Int = type Tuple[1]. //accessing by index

	List = type(X) [X]. // List of elements of type X.
	IntList = type List(int). // type function to construct List of ints.</programlisting>

	<section>
	<?xxe-sn 2f0cduzin5j -wunr7fl0rw8v?>

	<title><?xxe-sn 2f0cduzin5j -wunr7fl0rw8u?>Slave Types</title>

	<synopsis><?xxe-sn 2f0cduzin5j -wunr7fl0rw8t?>SYNTAX:
	slave //predicate//
	</synopsis>

	<itemizedlist>
	<?xxe-sn 2f0cduzin5j -wunr7fl0rw8s?>

	<listitem>
	<?xxe-sn 2f0cduzin5j -wunr7fl0rw8r?>

	<para><?xxe-sn 2f0cduzin5j -wunr7fl0rw8q?><emphasis><?xxe-sn 2f0cduzin5j -wunr7fl0rw8p?>predicate</emphasis>
	Name of a logic predicate</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 2f0cduzin5j -wunr7fl0rw8o?>Slave type is a reference to a
	type defined on the Transcend side. This gives Transcend a full control
	over program types marked as <code><?xxe-sn 2f0cduzin5j -wunr7fl0rw8n?>slave</code>
	ones. The type is constructed in such a way that variables of this type
	are able to hold <emphasis><?xxe-sn 2f0cduzin5j -wunr7fl0rw8m?>predicate</emphasis>'s
	arguments. Type inference works as follows:</para>

	<itemizedlist>
	<?xxe-sn 2f0cduzin5j -wunr7fl0rw8l?>

	<listitem>
	<?xxe-sn 2f0cduzin5j -wunr7fl0rw8k?>

	<para><?xxe-sn 2f0cduzin5j -wunr7fl0rw8j?>If a predicate has only
	one argument then a constructed type is a type of this argument:
	<code><?xxe-sn 2f0cduzin5j -wunr7fl0rw8i?>int</code>,
	<code><?xxe-sn 2f0cduzin5j -wunr7fl0rw8h?>string</code>, variant or
	tuple.</para>
	</listitem>

	<listitem>
	<?xxe-sn 2f0cduzin5j -wunr7fl0rw8g?>

	<para><?xxe-sn 2f0cduzin5j -wunr7fl0rw8f?>A constructed type is a
	record in case of several arguments.</para>
	</listitem>

	<listitem>
	<?xxe-sn 2f0cduzin5j -wunr7fl0rw8e?>

	<para><?xxe-sn 2f0cduzin5j -wunr7fl0rw8d?>Predicates correspond to
	variants in a constructed type.</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 2f0cduzin5j -wunr7fl0rw8c?>An example; Transcend
	facts:</para>

	<programlisting><?xxe-sn 2f0cduzin5j -wunr7fl0rw8b?>person("John", 1962).
	person("Bill", 1961).</programlisting>

	<para><?xxe-sn 2f0cduzin5j -wunr7fl0rw8a?>The Brute side:</para>

	<programlisting xml:id="SlaveTypes1"><?xxe-sn 2f0cduzin5j -wunr7fl0rw89?>name="tests/transcend.cpp: Transcend.Doc_SlaveTypes1", lines=15
	PersonNative = type {string, int}.
	Person = type slave person.</programlisting>

	<para><?xxe-sn 2f0cduzin5j -wunr7fl0rw88?>In the example above the types
	<code><?xxe-sn 2f0cduzin5j -wunr7fl0rw87?>PersonNative</code> and
	<code><?xxe-sn 2f0cduzin5j -wunr7fl0rw86?>Person</code> are
	equivalent.</para>
	</section>
	</section>

	<section>
	<?xxe-sn 2ey6qxf8um8 19?>

	<title><?xxe-sn 2ey6qxf8um8 1a?>Variants</title>

	<para><?xxe-sn 2ey6qxf8um8 1b?>Sometimes it is useful for a variable to
	have an ability to hold values of different types depending on some
	conditions, in other words to have a <emphasis><?xxe-sn 2ey6qxf8um8 1c?>variant
	type</emphasis>. An example:</para>

	<programlisting xml:id="Variants1"><?xxe-sn 2ey6qxf8um8 1d?>name="tests/ast.cpp: AST.Doc_Variants1"
	Color = type variant {
	White, Black, Magenta,
	CustomColor:: {r:: int, g:: int, b:: int}
	}.

	draw = function:: int
	{
	clrBorder = Black():: Color.
	clrBackground = CustomColor(50, 50, 50):: Color.

	drawRectangle({0, 0, 100, 100}, clrBorder, clrBackground)
	}</programlisting>
	</section>

	<section>
	<?xxe-sn 26yv439af40 ei?>

	<title><?xxe-sn 26yv439af40 ej?>SWITCH VARIANT Statement</title>

	<synopsis><?xxe-sn 26yv439af40 ek?>SYNTAX:
	switch variant ( //condition// [-> //alias// ] [:: //type// [; //annotations//... ] ] ) :: type [; annotations... ]
	[ case ( //guard// ) //case-branch// ]...</synopsis>

	<itemizedlist>
	<?xxe-sn 26yv439af40 el?>

	<listitem>
	<?xxe-sn 26yv439af40 em?>

	<para><?xxe-sn 26yv439af40 en?><emphasis><?xxe-sn 26yv439af40 eo?>condition</emphasis>
	Expression of a variant type.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26yv439af40 ep?>

	<para><?xxe-sn 26yv439af40 eq?><emphasis><?xxe-sn 26yv439af40 er?>alias</emphasis>
	Identifier to denote unwrapped content of the <emphasis><?xxe-sn 2ey6qxf8um8 1e?>condition</emphasis>
	expression withing case branches.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26yv439af40 es?>

	<para><?xxe-sn 26yv439af40 et?><emphasis><?xxe-sn 26yv439af40 eu?>guard</emphasis>
	Name of a variant to match against actual condition's variant.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26yv439af40 ev?>

	<para><?xxe-sn 26yv439af40 ew?><emphasis><?xxe-sn 26yv439af40 ex?>case-branch</emphasis>
	Code block to execute in case of the matched variant. The
	<emphasis><?xxe-sn 2ey6qxf8um8 1f?>condition</emphasis> expression's
	content is referred to by <emphasis><?xxe-sn 2fadpf0i3zr -wunr7fl0rw8t?>alias</emphasis>
	within the branch.</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 26yv439af40 ey?>Variant variables require special means to
	test which exactly variant they contain at any given moment as well as to
	access it. Usually, languages that support variant types(ADT) solve this
	problem be means of <emphasis><?xxe-sn 2ey6qxf8um8 1g?>pattern
	matching</emphasis>. Xreate intentionally does not support pattern
	matching since it is depends on parameters order, which is plainly
	unacceptable; besides, it's hardly usable in case of a large amount of
	parameters. Instead, Xreate supports special syntax to <emphasis><?xxe-sn 2ey6qxf8um8 1h?>unwrap</emphasis>
	a variable's content using <code><?xxe-sn 2ey6qxf8um8 1i?>switch variant</code>
	statement.</para>

	<para><?xxe-sn 26yv439af40 f0?>An example:</para>

	<programlisting xml:id="VariantsSwitch1"><?xxe-sn 26yv439af40 f3?>name="tests/ast.cpp: AST.Doc_VariantsSwitch1",lines=15
	Month = type variant {
	MonByName :: {name:: string},
	MonById :: {id:: int}
	}.

	nextMonth = function(month:: Month):: Month
	{
	switch variant(month):: Month
	case (MonByName)
	{
	monthName = month["name"]:: string. //here month has {name:: string} type

	MonByName(nextMonthByName(monthName))
	}

	case (MonById)
	{
	monthId = month["id"]:: int. //here month has {id:: int} type

	if(monthId == 11):: Month
	{ MonById(0) }
	else
	{MonById(monthId + 1)}
	}
	}</programlisting>

	<para><?xxe-sn 26yv439af40 f4?>The function <code><?xxe-sn 2ey6qxf8um8 1j?>nextMonth</code>
	computes the next month after a given one. The parameter <code><?xxe-sn 2ey6qxf8um8 1k?>month</code>
	can't be directly accessed due to being of a variant type; hence, It
	should be <emphasis><?xxe-sn 26yv439af40 f8?>unwrapped</emphasis> before
	using. As seen in this example, Xreate silently defines a new variable
	with the same name <code><?xxe-sn 2ey6qxf8um8 1l?>month</code> which holds
	an unwrapped content for each <code><?xxe-sn 2ey6qxf8um8 1m?>switch variant</code>'s
	branch independently.</para>
	</section>

	+ <section>
	+ <?xxe-sn 2fds09lgw74 m?>
	+
	+ <title><?xxe-sn 2fds09lgw74 n?>Versions</title>
	+
	+ <synopsis><?xxe-sn 2fds09lgw74 o?>//identifier// [{ //version// }]</synopsis>
	+
	+ <itemizedlist>
	+ <?xxe-sn 2fds09lgw74 p?>
	+
	+ <listitem>
	+ <?xxe-sn 2fds09lgw74 q?>
	+
	+ <para><?xxe-sn 2fds09lgw74 r?><emphasis><?xxe-sn 2fds09lgw74 s?>version</emphasis>
	+ Number to specify the identifier's version.</para>
	+ </listitem>
	+ </itemizedlist>
	+
	+ <para><?xxe-sn 2fds09lgw74 t?>Versions is a language construct to deal
	+ with mutable data. An example: </para>
	+
	+ <programlisting xml:id="Versions1_1"><?xxe-sn 2fds09lgw74 v?>name="tests/ast.cpp: AST.Doc_Versions1"
	+Date = type {year:: int, month:: string}.
	+
	+test = function:: Date; entry
	+{
	+ x{0} = {year = 1953, month = "March"}:: Date.
	+ x{1} = x{0} + {month = "February"}:: Date. //updates a single record's field
	+
	+ x{1} //returned value
	+}</programlisting>
	+
	+ <para><?xxe-sn 2fds09lgw74 w?>In the example above <code><?xxe-sn 2fds09lgw74 x?>x{0}</code>,
	+ <code><?xxe-sn 2fds09lgw74 y?>x{1}</code> are different versions of the
	+ same variable. This is a simple trick with the idea that for all intents
	+ and purposes <code><?xxe-sn 2fds09lgw74 z?>x{0}</code>, <code><?xxe-sn 2fds09lgw74 10?>x{1}</code>
	+ behave like different variables but really aren't. All analyses treat them
	+ as different immutable variables, yet the compiler actually uses the same
	+ memory address for them making this an update of a variable. It is a hint
	+ from a developer that the only one version of a variable should be
	+ available at any given time. The only analysis that knows the truth is the
	+ versions analysis. It is responsible for code validation in order to make
	+ sure that there is no expression that uses an outdated/unknown/unreachable
	+ variable's version. An another (counter)example:</para>
	+
	+ <programlisting xml:id="Versions1_2"><?xxe-sn 2fds09lgw74 11?>COUNTEREXAMPLE, name="tests/ast.cpp: AST.Doc_Versions1"
	+x{0} = 8:: int.
	+x{1} = x{0} + 10:: int.
	+y = x{0} + x{1} :: int. //invalid code: uses several versions</programlisting>
	+
	+ <para><?xxe-sn 2fds09lgw74 12?>The versions analysis builds a variables'
	+ liveliness graph to track versions usage and reveal situations when it's
	+ impossible to compute an expression due to the fact that it refers to an
	+ (possibly) outdated or unreachable version.</para>
	+ </section>
	+
	<section>
	<?xxe-sn 2ey6qxf8um8 1t?>

	<title><?xxe-sn 2ey6qxf8um8 1u?>Records</title>

	<para><?xxe-sn 2ey6qxf8um8 1v?>Record's elements(fields) are denoted by
	strings in order to access the field's value. This gives a possibility to
	use variables to reference fields. Such references are statically resolved
	during <link xlink:href="/d/concepts/interpretation/"><?xxe-sn 2ey6qxf8um8 1w?>Interpretation</link>.
	An example:</para>

	<programlisting xml:id="RecField1"><?xxe-sn 2ey6qxf8um8 1x?>name="tests/ast.cpp: AST.Doc_RecField1"
	Employee = type {
	name :: string,
	surname :: string,
	signature:: string
	}.

	test = function:: string; entry
	{
	employee = getAnyEmployee():: Employee.
	primaryKey = "surname":: string.

	employee[primaryKey]
	}</programlisting>

	<para><?xxe-sn 2ey6qxf8um8 1y?>In Xreate the left side of any assignment
	is always an identifier, hence there is special syntax to update one(or
	more) record's fields. An example:</para>

	<programlisting xml:id="RecUpdate1"><?xxe-sn 2ey6qxf8um8 1z?>name="tests/ast.cpp: AST.Doc_RecUpdate1"
	Day = type {
	year:: int,
	month:: string,
	day:: int
	}.

	test = function:: Day
	{
	tomorrow

	today = {year = 1936, month = "July", day = 21}:: Day.
	tomorrow = today + {day = 22}:: Day.
	}</programlisting>
	</section>
	</chapter>
	<?xxe-revisions
	+#12 2019-05-18T10:27:21Z pgess
	#11 2019-05-16T15:13:16Z pgess
	+1sPEAAABgrx7AB6CqmEAAA0Kc4KgXyMMExVzDFOJVQCCpF+8GXuB9w0=
	+
	#10 2019-05-14T16:34:55Z pgess
	1sPEAAABgqphAIIggqpoAAaBG3dBQUFBQWJzv1AjBCMEE4RkgwQTCmOBOgEBE2xTiFwBATMHQwdj
	CmMMQwkzNlOhIiMFY4FBAQFDB0OMaRMEYw1jgSeTDlObCxMEM4Eokw5jBlODUoMEQwtDgTYjGzOO
	fHMEU4EoczczgVoBAVMKEwkTY1O5bmMOU5h0gwUzgSmTDlOCDIMOMwczgUEBARMHEwUTBGOBADMH
	/FMEYwQzBTOaMwDNRoGSNL9Ua7sthG6Nd4IllD7zLaMjhFm1Io50iz6BhXChJLgGgUe6Y65QjHdj
	gTK3apsNY4lggTlrjBWDXYUrgU7qjn5ogVyTGbBmjgCCT4GjFLl4RJh2Y4E0MYJCgh3EPLFuiV2B
	TYGnTJAbgZsahG2bCYkd
	-
	#9 2019-05-11T15:02:16Z pgess
	1sPEAAABgqpoAD+CqnAAAB8Zc4H2HhMEE4IfQwRTgUFDCWMFgwSDEBMWQxBTEDOwEgCB/lCB9iCe
	IoIhjnGFA1BBhiuDdtNXghU=
	#8 2019-05-11T12:29:03Z pgess
	1sPEAAABgqpwACuCmDkAABQQc4HfExMNQ44+Ex9DCxMVIwwzqhAAqyWBs26pSIGWIoNAIb8Z
	#7 2019-05-10T16:50:38Z pgess
	1sPEAAABgpg5ABaCl1YAAAkGc4HefRMlQ7g0AKcLgbh6
	#6 2019-05-09T19:09:59Z pgess
	1sPEAAABgpdXAItQgfpzAGWGFYRNIGNjY2NtcHFjdGN1Y3gsIGljeS5QbW9VZz8+W2hvZHA6OnFy
	ZHNkdCB3IGR4KGR5ej8+SGYgLCBlM2VlZWJjPz5laW8uIGFuZCBDV2l6TGVmaWo/PiJOID0oIkE1
	ZmY3VjlmYmZzq2sTBkOmGVMEU95tAQFjjjETLUOBXGMMUyABARMEQxATCwEBQwZjCFMmAQFDBJMQ
	gwsBAUMEMwozBjMOEw1TRTNwQwsjJxMEkxBjDAEBU00zDTMsEwUjHBMEkxBTDAEBUzYBAWMogywT
	BCMdExSDC75TJYMLAQIzCmMEgyxDBIMdEwSTEIMLAQJjBAEDQwRDJoMLAQJjEQEBQyCDgSi7YwYT
	BDMEYyVjBUMNvhMEMwdjBkMGYyxDdwEBQxETCEMdUwRDBEMLEwdjgzFzHQEEQyIBAUMaEwSTB2Ml
	M2tDE4MLMwRDBXMJYzeTUHMdAQFjGIMLAQJDEQECgyIBAVMUMwQjLwEBEwRTEjMOUzaDCwECYyqD
	CwECQxABAWMRM1BzHQEBQwkBAVMWgwsBAmMUUwQBAVMgAQJzFIMFIzTGQwhDB1MFUwXfUwgTCmMG
	UzQBAUMOUwpzBhMJAQJTDnMIUwozUCMcAQJDB2MhoxMJUw6TB3MpYwRTDDMMIwlzE2MMYwhTBDMO
	kywTIAEBEwSTEGMMEwRTIFMFUwYzBTMNIyIBApMRcwSTB3MmAQNDBVMRMxZzE4MLAQFTBAECQwkz
	DCMEMwZTCgECUwRzCFMpEyQzKRMIAQFDC2MfU4EBYwpTgSJDPDMlQwUTBQEDUw9DBGMEUwUTCJMf
	YzFTBWOCMVMLEwRDCzM1M1lTKkMJY4ElEwQjDRMQEwdTE5OBFGMkQwUzDAEBUyQBAWMQQwQTBxMM
	YxCDG0MEQy4zBCMFgxBjLdUjIQEBYxsjCYMbUwS+EwUjBGMIYwQjBlMEIxwBAjMQgwRzCyMewiMI
	EwozLYMLQykBAWMdUwUzBTMPpCMEMwkzEoMFYwUTBbIzBAEDUwVDBIMFUwSDBWM0gwiTHgEBgxBj
	BEMHEwUzBpMcAQFzBEMNEwWTEIMLAQIjDYMHsGMGQwwzCBMFQ1IzECMdAQFTCDMSUwSDBBMIQwUT
	BFMPgxsBAUMEMw1jBlMEEwcjHgEBQxNjDZMKUxETFNMzWpMFMwZDBCMEEwcTBDMFUwQjBkMhYwsA
	qnuBBoGAJqYbhGSPKY5fiimCFY0Qi1eDNFP0Q8xS3kGVtMxa0xi5M4MZ2TpNVI0bgjbOS5U7Dfh0
	gjTPD4FIuQWV+XYNN/O6QIFNnRG0kQKBlAK0l0WZQvOPBPCEfpW0gaYngSFZtDIS84GMU64hhByp
	f5EljRgIrxy4NrxllBfZO4cq2DZ7gatJJGPHIwqBniwT9YQ9g1WMOZWKIkOFa7SBCoGbZdgnAPVO
	tIxhCb5yhn2DYYpykQOJd4HDM7RDtDcSEvVOiFu0Lbc2oQgmhoNkkH+6JL1PwgKleo1AoV2EHqxI
	HzaOal6B2GUttRcLkyROrQP/cIVw7XCVK8sfjSm/F5ACJJEzgUjGTg2ap2+PV5WeFINAgdo/zif4
	W7ooiA+NYK85lSuHZ4VXEyS0tE6xV4GdaptuwVahaSbsFKkkg0KFfYG2fIVgaIVWgQziCYg+7V/B
	ESWOJItgjnuDRN2MS/IwOqJUiUqCRYN2QVyBd3KB2CuCevMi3VaiJmWBFpVOLVgl9mjdeIY1g2z4
	gZ9+gZACr1SDL2lbmQCRGFmBfPiUCLVAjnOuQPsahzaHbuVekkKBjgbKbz6OTZIQi1OB5Au0lC46
	9WRGMIQfl3mB7HuvRbwclSwSgT4MtlG8nGisgwfFtA2ScYR2lFmBsxdzo4J0gYM8lbSxWlaGIYGD
	Ca4zjR2tZjyEU4E5yDiBGq8OpdQtmA6ILK1M+LhZvlAOzQKoFIEfzkKcTtOBqAiDK6d8mDZ6gQiJ
	YQHpAeE6gZAGjG+GVoGREZFW
	#5 2019-05-09T12:03:54Z pgess
	1sPEAAABgfpzACWB+mcAABMLc9olIwUTI1OOcWOBRTNEQ4GPIADkTdoqJY51gUlG
	#4 2019-05-07T18:27:55Z pgess
	1sPEAAABgfptAIxXgeQoAEuGeYUKYXBwYW9uYnVpbHQtaW5yZWN1cnN2dGFraXIuIEFsc3IrR3Mu
	IFBkYWwvL0lGUyAvL1JXaGlsaXVuZG9ub2hpYXh5aW5wdWMyM2M0c4ohExRDC0MEExBzCyMEIwRT
	BEMIQwQTBWMGAQQTBRMEvfxDBFMNAQhDB2MOAQYzBFMMMwpjBgEBYwgTFlOQFGMMY40pM5BEIwRj
	CGMEUzNTBFOBcGMEQwUTBzM1Y1wTBEMMY4FtkwSTDDMUIwZjgRdDL4OBFBMqYxWTEGM2YwtjKyMF
	AQMzBEMMUwUTBmMFAQIzBAEFMwRjBxMKQwsTZjMFEwgBAUOBJDMlYwpTClMhUwljgQ8BAVOBOGMH
	gwpjgU7fQwhTBoMKEzVjYkMEMxBTGnMVkxCDG2MEYzYzBTMGM19jTFMMMx9TQxMGAQRjNEMPU2Yj
	BxMGAQFjBgECYwdDSmMHQxxTE2MbMwgTBlMHcwRjBTMEQ0djCYMbYwRTKJMIMw6DGkM5Y1ozEUMg
	U4E3YydzCpMHQyozgUdjBkMJ8DOBGwECM4UagxMjBUMmUxEzgWdTDRMFMxBTFnM1U1kzREOBJyMH
	Ux5zFZMQgxszBFMHMwozH2NLM2KTKEOBPwEBYwgBAVMKIwYTBUMhg1JjNGMEQ2mDBzMKAQIzBzMQ
	gwQzgV1jHlM1U19DOXMVkxBTdjMGEwZDT1MHMxEBAWMFQwhTIVMvU1oTBGNbEwVDF2MVMwRTBzMK
	Yz0zBkMWEwozgQAzHmMFQ4FNAQQTBBMFYwQzCmNWMwQzBwEB+xMEkwZDB1MJu1MQAQITBUMHkwZj
	JFMIQw0TBGMgQzhTBlMdMwkBAiMHMzJDDxMKcwTTQx8jJTMEIxNTMDMhEwdDOmMLMxwTC0NVUwUj
	DlMFUwczBjM9EwSTBEOBHXMEMw2TBnMHMxATB0OBEVMJYxIzBXMWQwYBASMIEwYTBhMEMwRTJlMK
	Qx9TgTeTBhMEYw9DB2MNUxQzKoMEM4FZUwtDB3OBEEMhUxFjD3M1Y4EVkwtTNTOBE0MoEwRTgRQz
	CzM4YxUTEIMbUwRTByMGY01DE1MhU2wzShMEcwkTBBMHIwtjBTMFMxhDBIMVQwUTBCMFQwczQTMc
	AQFDFFMEUxljOYMhQ4MfIyJjBGOBfnMLgwdTgRBzIYMRcw+TNTOBFVMFcwRzCTM4QyBTBGMcEwQz
	IAEBMxdzFZMQIxwBAWMQAQRTIkMdgwQjIFM6IwdDIGMeExYzgRqTBWMGMwVTMYMbAQIjCUMXUx0B
	AUNREwsBAmMVcwtTCkO8UQCFAo01hU6DdDe5Z/QEmjzLAIMXuW2XHJRuhg+8KIMExR+BLaEiL8NA
	qXgqhxYRhiuDdpd2khyKItFglReDYJBcjmQ7rFTKYqgUhxCXeIVkYA3kbIF/600dgRtgjXiudSGB
	ZpRuQ8hasSxCjzXCTp8smBa8c7ZO0nmDGcgHuGiJQ3mBJYsmo0mdeZMqkmKBEs5D7YFJgTTJZY1g
	7cRgi0FKZhHVIfRbesRjgwlAYYEDgTIjsFZbSCLWfYtIkQ2BPMxPgkkJNRcoiUSoVQ+pAYJygTni
	VPSBMo11E6UAlJFRQ4JnD4IOgUDVK4ZNeekOhg35gWKBHYiKcYU2dDuGWLEIpGSCCdVMW0X0CYEu
	1SH0X+QPj3JMI0/6gQ2BRYFI7w2VLAoi0WKpU4JWiKRKjAyBB/kYmGeeTII2YtUhX55OhCSBCK1x
	V6RMn12ZTkAxx11hqmtrI+gIjB8kDpBN2WeLU2SBA/IkJbVOo0flaMg0jHfPFVmGGrdy7YYqgmKe
	EIFqtVcVbxGmZzKJYBc+rCZYgnqpVTiZWrlkD4F81WSpblOIERsy4ygqQw2uIS/hCYN+rDsVg18K
	t3FVXcyBI+0XgVPseIlemXCBIYl5aNdGjXmBi1P7MIV61h+MIN9ltgBQsIRi+RChQbg+P5xK+TKB
	ZcBwY4ETI5V+Y1chgSA2gReWKS3IcYEn3SyKIfR5gTWcEwxRjkM4b+BKv7llhBeZXudFy0gtpHpa
	jCTpeMc3nFaZBEMfLxYEYlqSTqxjg0VTaYIa9hkXUEWmCQ9Wh3GBgg+bfYF7hH6BiAPaMdUhkBod
	6HjFMYGBUkavC0Uksm2COvePA4h8gS30u36kWotSRIM0aSvgeIIf
	#3 2019-02-23T12:37:01Z pgess
	1sPEAAABgeQqAIgmgeMrAHyEMoJvNTM1NTVnLCwgaGlzaWNzOiBxdWU1NWssIGx0ZXJmYWNFeHRl
	cm4tQzVvNXBxPz5POiwgVnN0T2lpbmZsdS4gc3c2Zz8+NSwgNnA/PissIC0sICosIDZ0LCAhPSwg
	NnU2dywgIDcxID03Mi4gID0gIC0gICBoLmFzc29jZHOEEBMEEyQBAUMEIw0BARMZQwRTHNNjGgEB
	MwVDGwECEwoBATMM5FMMIwiTHQEBUwQTCSMnAQFTBEMEAQljBEMpAQETBXMbAQJDDQECYw0jCHMd
	AQEzFXMIcx1jBQEGEwQBCCMsYwVzGwECYzEBAkMGIyjEAQEjCquDC0MiMwRTHQEBIwmDCIMdAQEj
	CiMnIwQjEBMlUwcTJVMEUxUzDkOBCFNIIwljTwEBQwUBAVMIIwpTBhMIQwkBBVMEMw1TBUMbYwlT
	HlMLAQIjJUMEEwUBAUMaAQEzBFMEUwgzBkMMcwlzDGNgYwtThysTCwEHMxxTLFNcMwYTBkMqYwRj
	JUMEQwQjCWMSIwUTBUM1gwQzJEMEUxITDIMEM4FsgwsBDWMJgyxDaIML4gEGQwgjBoMGIwQzBhMk
	gwu+gwpjbYMLAQJjCQECQwYjCQEBUw+DWSMGEwtjJxMEM2pTCCMJQxODCwECQwgjBIMHIwhjDGMG
	AQJzBmMGIwdTCpMGMwpjB4MTgwsBAlMGcwQjHQECQwQBA1MMIwhzK1OBBAEDQ4E7UwRTB3MJIzYz
	CjN3MwUTDoMMUw1DSEMRUwtTBFMEgwsTCyMKEx9DKwEBUxcBAWM9Iw0jIaUjC2MNMwxjMhMEcwu9
	Yw9jGgEFMwQBASMQkw4zNxMHM4EHUwZTIVMRM0pTCmMIEwRTL0MRUw9zBDMLM2VjUiMEM4IaIwlz
	K1MkMwpDBkMTMwUzB2MEUxITBTOBq2MAkmGRICyvPYMnizOEFiQhICCMYA6HDr9DSdKdMo4XNc0J
	r3S3I68FlX+xkEeDQjq5r3G5uasAoHKBYap2sYcRoSKBRo59pmsKK0m3RibGX5qan1wy5WyEXqkW
	i0qDdIRuKhkRgRuCJVKBN8cZnm+nPYV9g0qCDqZHgW5LyA2BBGuBGt9nh3MIrSfJEhuvPQ8bNYNq
	MWuDNIdjjQxJf4QYGK8eLJo9K6IWEL9dhBlL2zfSICqWSNsxtIJ46Ta0dFgKRBcHnzW0mhpEZbR6
	M4FpEummAJEAgliGYY8qgXXRD40xtJAJ8QrZgmQeu08IHcgiDiUbnlsStCr1iiqTVjqpIYlAgQm4
	QIFBZJ1YsSlYSI9gVhpiTOI0qSWoWjivb5sHjUueVSsX7XmKAKsignuXR3KCW5JxiJcbUxa5AUpQ
	N64nZKZngSSBECGGd7k7jTdeoBl1cYF0JmnfSViqNTWCT6ATyU8ysFQZo3QPqkEe
	#2 2018-12-18T15:50:51Z pgess
	1sPEAAABgeMqAFCB4lUAASggLXObCwEBE4EIIx9DFRMsY4GNb0MjQyITB1MEY4FhcyNTBBMFIzdD
	tF4Amw6BCYEpmU2BCIGXHoGOHowjjkUmXYgkgatoghiCZA==
	#1 2018-12-18T15:11:23Z pgess
	1sPEAAABgeJVADCB4lkAABkQc+xgE5kzQ5JQgwhTshozg19DkFhTCmODEwDsX5kyEZJXshmDXoYP
	ilQ=
	?>
	\ No newline at end of file
	diff --git a/documentation/communication.xml b/documentation/communication.xml
	index 1547364..e344954 100644
	--- a/documentation/communication.xml
	+++ b/documentation/communication.xml
	@@ -1,443 +1,497 @@
	<?xml version="1.0" encoding="UTF-8"?>
	<chapter version="5.1" xmlns="http://docbook.org/ns/docbook"
	xmlns:xlink="http://www.w3.org/1999/xlink"
	xmlns:xila="http://www.w3.org/2001/XInclude/local-attributes"
	xmlns:xi="http://www.w3.org/2001/XInclude"
	xmlns:trans="http://docbook.org/ns/transclusion"
	xmlns:svg="http://www.w3.org/2000/svg"
	xmlns:m="http://www.w3.org/1998/Math/MathML"
	xmlns:html="http://www.w3.org/1999/xhtml"
	xmlns:db="http://docbook.org/ns/docbook">
	<?xxe-sn 29tvny21340 1?>

	<title><?xxe-sn 29tvny21340 2?>Communication</title>

	<para><?xxe-sn 2abbls7nbb4 2?>The chapter discusses safe usage of non-local
	- variables, that is variables accessible by different components or threads
	+ variables, that is variables accessible by different components or threads,
	with global variables as a particular case.</para>

	<section>
	<?xxe-sn 29xq7jt0wzk 1?>

	<title><?xxe-sn 29xq7jt0wzk 2?>Syntax</title>

	<para><?xxe-sn 29xq7jt0wzk 3?>Annotations:</para>

	<synopsis><?xxe-sn 2afyauuaxvk d?>SYNTAX:
	commop(send) (1)
	commop(receive) (2)</synopsis>

	<itemizedlist>
	<?xxe-sn 2afyauuaxvk e?>

	<listitem>
	<?xxe-sn 2afyauuaxvk f?>

	<para><?xxe-sn 2afyauuaxvk g?>annotation <code><?xxe-sn 2afyauuaxvk h?>(1)</code>
	marks <code><?xxe-sn 2afyauuaxvk i?>SEND</code> communication
	event.</para>
	</listitem>

	<listitem>
	<?xxe-sn 2afyauuaxvk j?>

	<para><?xxe-sn 2afyauuaxvk k?>annotation <code><?xxe-sn 2afyauuaxvk l?>(2)</code>
	marks <code><?xxe-sn 2afyauuaxvk m?>RECEIVE</code> communication
	event.</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 2afyauuaxvk n?>Specializations:</para>

	<synopsis><?xxe-sn 2afyauuaxvk o?>SYNTAX:
	commDirect
	commGuarded</synopsis>

	- <para><?xxe-sn 2afyauuaxvk p?>Communication reasoning able to assign
	- following specializations:</para>
	+ <para><?xxe-sn 2afyauuaxvk p?>Communication reasoning is able to assign
	+ the following specializations:</para>

	<itemizedlist>
	<?xxe-sn 2afyauuaxvk q?>

	<listitem>
	<?xxe-sn 2afyauuaxvk r?>

	<para><?xxe-sn 2afyauuaxvk s?><code><?xxe-sn 2afyauuaxvk t?>commDirect</code>
	— specialization is expected to provide direct access to raw
	variable's content.</para>
	</listitem>

	<listitem>
	<?xxe-sn 2afyauuaxvk u?>

	- <para><?xxe-sn 2afyauuaxvk v?><code><?xxe-sn 2afyauuaxvk w?>commGaurded</code>
	+ <para><?xxe-sn 2afyauuaxvk v?><code><?xxe-sn 2afyauuaxvk w?>commGuarded</code>
	— specialization is expected to do internal consistency checks at run
	time.</para>
	</listitem>
	</itemizedlist>
	</section>

	<section>
	<?xxe-sn 29tvny21340 3?>

	<title><?xxe-sn 29tvny21340 4?>Background</title>

	<para><?xxe-sn 29tvny21340 5?>One of the major concepts that support
	writing of safe programs is a notion of <emphasis><?xxe-sn 2abbls7nbb4 1?>immutability</emphasis>.
	Immutability tremendously simplifies many kinds of analyses; using
	immutable structures is a practical way to write multithreaded
	- applications and has many other benefits beyond that. However in its most
	- basic form it comes with a price of disastrous, in many cases, memory
	- overhead, since property of immutability stipulates for each change of
	- variable to make an independent copy of it occupying different memory
	- region. Unwise using of immutable structures lead to the situation such
	- that CPU is mostly occupied with unnecessary variables copying to and fro
	- as well as with extensive garbage collection, irrelevant of actual
	- algorithm's complexity at hand. Thus it is one of the central highlights
	- of proper programming language design to provide techniques to overcome
	- the shortcomings by relaxing immutability requirements keeping
	- nevertheless safety benefits. There are many ways to approach the problem,
	- and one such technique, namely <emphasis><?xxe-sn 2abbls7nbb4 3?>communication
	- model</emphasis> is discussed next.</para>
	+ applications and has many other benefits beyond that. However, in its most
	+ basic form it comes with the price of a disastrous, in many cases, memory
	+ overhead, since the property of immutability implies that with each change
	+ of a variable an independent copy of it shall be made, occupying a
	+ different memory region. Unwise use of immutable structures would lead to
	+ a situation where CPU is mostly occupied with unnecessary variables
	+ copying to and fro as well as with extensive garbage collection,
	+ irrelevant of actual algorithm's complexity at hand. Thus one of the
	+ central points of a proper programming language design is enabling the
	+ techniques that would help to overcome the shortcomings by relaxing the
	+ immutability requirements while keeping the safety benefits. There are
	+ many ways to approach the problem, and one such technique, namely
	+ <emphasis><?xxe-sn 2abbls7nbb4 3?>communication model</emphasis>, is
	+ discussed next.</para>
	</section>

	<section>
	<?xxe-sn 29xq7jt0wzk 5?>

	<title><?xxe-sn 29xq7jt0wzk 6?>Communication Model</title>

	<para><?xxe-sn 29xq7jt0wzk 7?><emphasis><?xxe-sn 2abizkj6e4g 1?>Communication
	- model</emphasis> is a way to capture and express what's going on with
	+ model</emphasis> is a way to capture and express what is going on with
	variables in a program as well as to define rules that describe valid
	- operations over variables. Within the framework writing value to a
	+ operations over variables. Within this framework, writing a value to a
	variable is viewed as <emphasis><?xxe-sn 29xq7jt0wzk 8?>sending</emphasis>,
	- and conversely reading variable's value is viewed as <emphasis><?xxe-sn 29xq7jt0wzk 9?>receiving</emphasis>.</para>
	+ while reading a variable's value is viewed as <emphasis><?xxe-sn 29xq7jt0wzk 9?>receiving</emphasis>.</para>

	<para><?xxe-sn 2abizkj6e4g 2?>Variables that are accessed from different
	components or threads are referred to as non-local variables. This chapter
	- is focused on a on-local variables, global variables particularly, since
	- exactly for them it's hard to manually check exhaustively where and how
	- they are used in order to catch any errors. It is natural to view them as
	- the means of interaction between different parts of a program, in other
	- words, interaction between sender and receiver, where sender and receiver
	+ is focused on non-local variables, the global ones particularly, since it
	+ is the very type of variables for which it is difficult to perform a
	+ manual exhaustive check and find out where and how they are used in order
	+ to catch any errors. It is natural to view them as the means of an
	+ interaction between different parts of a program, in other words, an
	+ interaction between a sender and receiver, where such sender and receiver
	are different components. The same terms comprise rules that express valid
	ways of interacting. The abstraction is named <emphasis><?xxe-sn 29xq7jt0wzk a?>communication
	model</emphasis> due to similarity with the network communication.</para>

	<para><?xxe-sn 29xq7jt0wzk b?>Reasoning based on working with a
	- <emphasis><?xxe-sn 2abizkj6e4g 3?>communication path</emphasis>, i.e chain
	- of <emphasis><?xxe-sn 29xq7jt0wzk c?>communication events</emphasis>(e.g.
	- sending/receiving) occurred during program execution.</para>
	+ <emphasis><?xxe-sn 2abizkj6e4g 3?>communication path</emphasis>, i.e a
	+ chain of <emphasis><?xxe-sn 29xq7jt0wzk c?>communication events</emphasis>
	+ (e.g. sending/receiving) that occur during program execution.</para>

	- <para><?xxe-sn 2abizkj6e4g 4?>Let's consider small example:</para>
	+ <para><?xxe-sn 2abizkj6e4g 4?>Let's consider a small example:</para>

	<programlisting><?xxe-sn 2abizkj6e4g 5?>a = init():: int; commop(send). //(1)
	b = a + 1 :: int; commop(receive). //(2)</programlisting>

	- <para><?xxe-sn 2abizkj6e4g 6?>It shows computing of variable
	+ <para><?xxe-sn 2abizkj6e4g 6?>It shows computing of the variable
	<code><?xxe-sn 2abizkj6e4g 7?>b</code>. Variable <code><?xxe-sn 2abizkj6e4g 8?>b</code>
	depends on <code><?xxe-sn 2abizkj6e4g 9?>a</code> so <code><?xxe-sn 2abizkj6e4g a?>a</code>
	is calculated first. Variables <code><?xxe-sn 2abizkj6e4g b?>a</code>,
	<code><?xxe-sn 2abizkj6e4g c?>b</code> are annotated with <code><?xxe-sn 2abizkj6e4g d?>comm(send)</code>
	and <code><?xxe-sn 2abizkj6e4g e?>comm(receive)</code>, denoting
	<emphasis><?xxe-sn 2abizkj6e4g f?>sending</emphasis> and
	<emphasis><?xxe-sn 2abizkj6e4g g?>receiving</emphasis> events,
	respectively. Communication path in this case is an ordered list
	<code><?xxe-sn 2abizkj6e4g h?>{<begin>, SEND, RECEIVE,
	- <end>}</code> where <code><?xxe-sn 2abizkj6e4g i?><begin>,
	- <end></code> — are special events that denote first and last events
	- in the path, respectively.</para>
	+ <end>}</code> where <code><?xxe-sn 2abizkj6e4g i?><begin> and
	+ <end></code> are special events that denote the first and last
	+ events in the path, respectively.</para>

	<para><?xxe-sn 2abizkj6e4g k?>The gist of using communication model is to
	ensure that <emphasis><?xxe-sn 2abizkj6e4g l?>every sent value is properly
	received</emphasis>. It relies on the compiler to gather all possible
	communication paths in the program as an input for processing. There are
	two supported modes of reasoning:</para>

	<itemizedlist>
	<?xxe-sn 29xq7jt0wzk d?>

	<listitem>
	<?xxe-sn 29xq7jt0wzk e?>

	<para><?xxe-sn 29xq7jt0wzk f?>Validation. In this mode all
	communication paths are checked against communication rules to confirm
	- that the program is valid. Otherwise compilation error is
	+ that the program is valid. Otherwise a compilation error is
	raised.</para>
	</listitem>

	<listitem>
	<?xxe-sn 29xq7jt0wzk g?>

	<para><?xxe-sn 29xq7jt0wzk h?>Planning. In this mode reasoning assigns
	proper implementation for variables in efforts to ensure
	validity.</para>
	</listitem>
	</itemizedlist>
	</section>

	<section>
	<?xxe-sn 29xq7jt0wzk j?>

	<title><?xxe-sn 29xq7jt0wzk k?>Validation</title>

	<para><?xxe-sn 29xq7jt0wzk l?>To perform validation, every communication
	- path is checked against number of communication rules that express which
	- communication path are valid. Default behaviour expressed by "every sent
	- value being properly received" produce next possible cases:</para>
	+ path is checked against number of communication rules that define which
	+ communication paths are valid. Default behaviour expressed by the "every
	+ sent value being properly received" presumption results in the next
	+ possible cases:</para>

	<itemizedlist>
	<?xxe-sn 29xq7jt0wzk 1w?>

	<listitem>
	<?xxe-sn 29xq7jt0wzk 1x?>

	- <para><?xxe-sn 29xq7jt0wzk 1y?>Valid. Path that consists of pairs of
	+ <para><?xxe-sn 29xq7jt0wzk 1y?>Valid. Paths that consist of pairs of
	events <code><?xxe-sn 29xq7jt0wzk 1z?>{SEND, RECEIVE}</code> are
	<emphasis><?xxe-sn 29xq7jt0wzk 20?>valid</emphasis> meaning that each
	- sent value is properly received.</para>
	+ sent value was properly received.</para>
	</listitem>

	<listitem>
	<?xxe-sn 29xq7jt0wzk 21?>

	<para><?xxe-sn 29xq7jt0wzk 22?>Undefined and expired value. Paths that
	- have parts <code><?xxe-sn 2abizkj6e4g m?>{<begin>,
	+ have the parts <code><?xxe-sn 2abizkj6e4g m?>{<begin>,
	RECEIVE}</code> or <code><?xxe-sn 2abizkj6e4g n?>{RECEIVE,
	- RECEIVE}</code> are invalid meaning possibly undefined value is
	- received in the first case or duplication i.e. expired value is used
	- in the second's one.</para>
	+ RECEIVE}</code> are invalid meaning that either a possibly undefined
	+ value was received in the first case or a duplication, i.e. an expired
	+ value, was used in the second case.</para>
	</listitem>

	<listitem>
	<?xxe-sn 2a3uy8rr2f4 5?>

	- <para><?xxe-sn 2a3uy8rr2f4 6?>Lost value. Paths that have parts
	+ <para><?xxe-sn 2a3uy8rr2f4 6?>Lost value. Paths that have the parts
	<code><?xxe-sn 2abizkj6e4g o?>{SEND, SEND}</code> or <code><?xxe-sn 2abizkj6e4g p?>{SEND,
	- <end>}</code> indicate possibly lost change since consequent
	- sender replaces value in the former case and sent value is not used at
	- all in the latter case.</para>
	+ <end>}</code> indicate possibly lost change since the consequent
	+ <code><?xxe-sn 2fhypj8av40 1?>SEND</code> event replaces the value in
	+ the former case while the sent value is not used at all in the latter
	+ case.</para>
	+
	+ <remark><?xxe-sn 2eeqemlan74 pu35zrt1abya?>Не вполне понятен смысл
	+ фразы "consequent sender", и перед ней нужен артикль</remark>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 29xq7jt0wzk 28?>Traditional immutability validation is
	- based on the idea that once valid value is valid as long it is unmodified.
	- In this regards communication model can be viewed as an extension and more
	- expressive tool since it also captures <emphasis><?xxe-sn 2afyauuaxvk 3?>value
	- expiration</emphasis> after it was used as well as <emphasis><?xxe-sn 2afyauuaxvk 4?>value</emphasis>
	+ based on a concept that a valid value shall remain valid as long as it was
	+ not modified. In this regard the communication model can be viewed as an
	+ extension and more expressive tool since it also captures
	+ <emphasis><?xxe-sn 2afyauuaxvk 3?>value expiration</emphasis> after it was
	+ used as well as <emphasis><?xxe-sn 2afyauuaxvk 4?>value</emphasis>
	<emphasis><?xxe-sn 2afyauuaxvk 5?>loss</emphasis>, if it was not used at
	all.</para>
	</section>

	<section>
	<?xxe-sn 29xq7jt0wzk 29?>

	<title><?xxe-sn 29xq7jt0wzk 2a?>Planning</title>

	- <para><?xxe-sn 2abizkj6e4g s?>Reasoning in the communication model aside
	- of performing validation, also assigns appropriate specialization for
	- sending and receiving operations, as appropriate. At the moment there are
	- two specializations the operations are expected to support:</para>
	+ <para><?xxe-sn 2abizkj6e4g s?>Aside of performing validation, reasoning in
	+ the communication model also assigns appropriate specialization to sending
	+ and receiving operations, as appropriate. At the moment there are two
	+ specializations the operations are expected to support:</para>

	<itemizedlist>
	<?xxe-sn 2abizkj6e4g t?>

	<listitem>
	<?xxe-sn 2abizkj6e4g u?>

	<para><?xxe-sn 2abizkj6e4g v?>Direct. Direct specialization
	<code><?xxe-sn 2abizkj6e4g w?>commDirect</code> is expected to provide
	- direct access to variable's value. This specialization is assigned in
	- case of fully statically validated communication path.</para>
	+ direct access to a variable's value. This specialization is assigned
	+ in case of a fully statically validated communication path.</para>
	</listitem>

	<listitem>
	<?xxe-sn 2abizkj6e4g x?>

	- <para><?xxe-sn 2abizkj6e4g y?>Guarded. In case if there are possible
	- communication path inconsistencies that can not be completely ruled
	- out at compile time, checking logic should be embedded into compiled
	- code. Specialization <code><?xxe-sn 2abizkj6e4g z?>commGaurded</code>
	- is expected to hold variable state and check usage consistency.</para>
	+ <para><?xxe-sn 2abizkj6e4g y?>Guarded. In case there are possible
	+ communication path inconsistencies that cannot be completely ruled out
	+ at compile time, checking logic should be embedded into compiled code.
	+ Specialization <code><?xxe-sn 2abizkj6e4g z?>commGaurded</code> is
	+ expected to track a variable's state in order to be able to check
	+ usage consistency.</para>
	+
	+ <remark><?xxe-sn 2eeqemlan74 pu35zrt1abyb?>"hold variable state" - ?
	+ Удерживать переменную в каком-либо состоянии? Зафиксировать ее
	+ состояние? Тогда может лучше "hold the [current] state of a variable"?
	+ Или даже seize?</remark>
	</listitem>
	</itemizedlist>
	</section>

	<section>
	<?xxe-sn 2a3uy8rr2f4 8?>

	<title><?xxe-sn 2a3uy8rr2f4 9?>Planning Horizon</title>

	- <para><?xxe-sn 2a3uy8rr2f4 a?>Reasoning implements algorithm that is
	+ <para><?xxe-sn 2a3uy8rr2f4 a?>Reasoning implements an algorithm that is
	bounded by the maximal path length it can process. The parameter is called
	<emphasis><?xxe-sn 2a3uy8rr2f4 b?>planning horizon</emphasis>. Any
	- variable that it can not check due to exceedingly large path's length is
	+ variable that it cannot check due to exceedingly large path's length is
	assigned default implementation <code><?xxe-sn 2abizkj6e4g 10?>commGaurded</code>
	that performs necessary checks during runtime. Thus the parameter
	- regulates trade off between static analysis extensiveness and runtime
	- checks overhead.</para>
	+ establishes a trade-off between the static analysis extensiveness and the
	+ runtime checks overhead.</para>
	</section>

	<section>
	<?xxe-sn 2a7t1hxqqyo 1?>

	<title><?xxe-sn 2a7t1hxqqyo 2?>Example: Direct Implementation</title>

	<programlisting xml:id="DirImpl_1"><?xxe-sn 2a7t1hxqqyo 3?>name="tests/effects-communication.cpp: Doc_DirImpl", lines=15
	import raw("scripts/dfa/propagation.lp").
	import raw("scripts/dfa/polymorphism.lp").
	import raw("scripts/effects-communication/communication.lp").
	import raw("scripts/effects-communication/config.lp").

	CommDirect = type {
	value:: int
	}.

	guard:: commDirect {
	init = function::CommDirect
	{
	{value = 0}
	}

	read = function(vault1:: CommDirect):: int
	{
	(vault1:: *;commop(receive))["value"]
	}

	write = function(vault2:: CommDirect, valueNew:: int)::CommDirect
	{
	(vault2:: *; dfa_pseudo(vault2)) + {value = valueNew}:: int; commop(send); dfa_uppy(vault2)
	}
	}

	main = function::int; entry {
	x1 = init()::*; dfa_polym(ret).
	x2 = write(x1, 1)::*; dfa_polym(arg).
	val = read(x2)::int; dfa_polym(arg).
	val
	}</programlisting>

	<para><?xxe-sn 2a7t1hxqqyo 4?>In this example, basic workflow is presented
	in <code><?xxe-sn 2afyauuaxvk 1?>main</code> — the function
	<code><?xxe-sn 2a7t1hxqqyo 5?>write(x1, 1)</code> is invoked following by
	invocation of <code><?xxe-sn 2a7t1hxqqyo 6?>read(x2)</code>. Functions
	<code><?xxe-sn 2afyauuaxvk 9?>write()</code> and <code><?xxe-sn 2afyauuaxvk a?>read()</code>
	are annotated with <code><?xxe-sn 2afyauuaxvk b?>commop(send)</code> and
	<code><?xxe-sn 2afyauuaxvk c?>commop(receive)</code> respectively in order
	to enable communication reasoning. Analyzer gathers and validates observed
	- communication path and since there is no ambiguity, it's possible to
	+ communication path, and since there is no ambiguity, it is possible to
	assign specialization <code><?xxe-sn 2a7t1hxqqyo 7?>CommDirect</code>
	allowing direct access to the variables avoiding any additional overhead.
	- Note, there are no any other specializations defined and if reasoning was
	- not enable to conclude that it is the case the compilation error would be
	- raised.</para>
	+ Note, there are no other specializations defined, and if reasoning was not
	+ able to conclude direct access specialization, then the compilation error
	+ would be raised.</para>
	+
	+ <remark><?xxe-sn 2eeqemlan74 pu35zrt1abyc?>"is invoked following by
	+ invocation" - тут из-за грамматики не ясно, что за чем следует. Предлагаю
	+ заменить на "is invoked after the invocation of...", или на "is invoked
	+ following the invocation of..."</remark>
	+
	+ <remark><?xxe-sn 2eeqemlan74 pu35zrt1abyd?></remark>
	+
	+ <remark><?xxe-sn 2eeqemlan74 pu35zrt1abye?>\| "if reasoning was not able to
	+ conclude that it was the case" - лучше уточнить что подразумевается под
	+ словами "that it was the case" - "расшифровать", т.к. мне например не
	+ понятно</remark>
	</section>

	<section>
	<?xxe-sn 2a7t1hxqqyo 9?>

	<title><?xxe-sn 2a7t1hxqqyo a?>Example: Guarded Implementation</title>

	<programlisting xml:id="GuardedImpl_1"><?xxe-sn 2a7t1hxqqyo b?>name="tests/effects-communication.cpp: Doc_GuardedImpl", lines=15
	import raw ("scripts/effects-communication/communication.lp").
	import raw ("scripts/dfa/propagation.lp").
	import raw ("scripts/dfa/polymorphism.lp").
	import raw ("scripts/effects-communication/config.lp").

	CommState = type variant{Invalid, Valid, Outdated}.

	CommDirect = type {
	value:: int
	}.

	CommGuarded = type {
	value:: int,
	state:: CommState
	}.

	guard:: commDirect {
	init=function::CommDirect{
	{value = 0}
	}

	read= function(vault1:: CommDirect):: int{
	(vault1::CommDirect; commop(receive))["value"]
	}

	write= function(vault2:: CommDirect, valueNew1:: int)::CommDirect{
	(vault2::CommDirect;dfa_pseudo(vault2)) + {value = valueNew1}:: int; commop(send); dfa_uppy(vault2)
	}
	}

	errorRead = function:: int { -1 }

	errorWrite = function:: CommGuarded{
	{
	value = -1,
	state = Invalid()
	}
	}

	guard:: commGuarded{
	init=function::CommGuarded{
	{
	value = 0,
	state = Invalid()
	}
	}

	read=function(vault3:: CommGuarded):: int {
	switch variant (vault3["state"]->whatever::CommState;commop(receive)):: int
	case (Invalid) { errorRead() }
	case (Outdated) { errorRead() }
	case (Valid) { vault3["value"] }
	}

	write=function(vault4:: CommGuarded, valueNew2:: int)::CommGuarded{
	switch variant (vault4["state"]->whatever::CommState;commop(send); dfa_pseudo(vault4))::int
	case (Invalid) {
	{value = valueNew2, state = Valid()}:: CommGuarded; dfa_uppy(vault4)
	}

	case (Outdated) {
	{value = valueNew2, state = Valid()}:: CommGuarded; dfa_uppy(vault4)
	}

	case (Valid) { errorWrite():: CommGuarded; dfa_uppy(vault4) }
	}
	}

	main=function(cmd:: num)::int; entry {
	x1 = init():: *; dfa_polym(ret).
	x2 = write(x1, 1)::*; dfa_polym(arg).

	x3 = if (cmd > 0)::int {
	y = read(x2):: int; dfa_polym(arg).
	y

	} else {
	z = write(x2, 2)::*; dfa_polym(arg).
	a = read(z):: int; dfa_polym(arg).
	a
	}.

	x3
	}</programlisting>

	- <para><?xxe-sn 2a7t1hxqqyo d?>Here example of slightly more complicated
	- workflow. Function <code><?xxe-sn 2afyauuaxvk 2?>main</code> contains
	- branching that depends on argument known at run time only. Analyzer is
	- presented with two possible communication paths and one of them(false
	- branch) leads to a possibly lost value for it contains two consequent
	- <code><?xxe-sn 2afyauuaxvk 6?>SEND</code> events. In this situation the
	- analyzer unable to statically validate correctness and assigns
	- specialization <code><?xxe-sn 2afyauuaxvk 7?>commGuarded</code> to embed
	- checking logic into compiled code as an intermediary layer between
	- variable's content and client's code. Implementation <code><?xxe-sn 2afyauuaxvk 8?>commGuarded</code>
	- along with a variable access also tracks the variable status and returns
	- error if the value is inconsistent.</para>
	+ <para><?xxe-sn 2a7t1hxqqyo d?>Here is an example of a slightly more
	+ complicated workflow. Function <code><?xxe-sn 2afyauuaxvk 2?>main</code>
	+ contains branching that depends on an argument known at run time only.
	+ Analyzer is presented with two possible communication paths, one of which
	+ (the false branch) leads to a possibly lost value for it contains two
	+ consequent <code><?xxe-sn 2afyauuaxvk 6?>SEND</code> events. In this
	+ situation analyzer is unable to statically validate correctness and
	+ assigns specialization <code><?xxe-sn 2afyauuaxvk 7?>commGuarded</code> to
	+ embed checking logic into compiled code as an intermediary layer between
	+ the variable's content and the client's code. Implementation
	+ <code><?xxe-sn 2afyauuaxvk 8?>commGuarded</code> besides accessing to a
	+ variable's value also tracks the variable's status and will return error
	+ if the value is inconsistent.</para>
	+
	+ <remark><?xxe-sn 2eeqemlan74 pu35zrt1abyf?>"along with a variable access"
	+ - ? Если буквально переводить, получается "вместе с переменным доступом".
	+ Нужен или апостроф после variable, или как-то перефразировать.</remark>
	</section>
	</chapter>
	<?xxe-revisions
	+#4 2019-05-20T09:53:54Z pgess
	+#3 2019-04-30T23:02:25Z Администратор
	+1sPEAAABgYxnAHuBjAYAA0EwcmVyc6gYEwQBAUMJQ4IpYwlTEmOYMGMEUwcTBAECMwhTBlMuQwQz
	+jhpTE2MFEwUTB1MLQ5ceMxRTBEMHM55BYxxjgzgAlhLDR5IYqxOLE4JIP5g4hnw4lmAOtlMxjxeH
	+B7lDhDGLepk/mzgdmVuXRYIlgRo=
	+
	+#2 2019-04-29T21:50:35Z Администратор
	+1sPEAAABgYwHAINs/zEAFYINgUJvZHVjLidpZGVhdW5yZWdzICdtKHNzuW4TCkMEUw5jBTMEYyZT
	+LQEEY4EVMw0TBUOBH1MUUwoTIGNcY4EXQwczElMFUxwzCxMEAQFDDmMFUwRjB2MGpHMKY2mDIlOB
	+ExMFIwQTCDMKMwRjDjMsgwwzIGM/QwQBBFMGUwRDDRMFUwxjBgECMxhjBFODSEMKgxwzH1MoQwQz
	+gm5TPWOBFTMGEweDGzMZIwUzgWmDDJMQUx8zClNxMwhjgS2DBTMFQ4FBqr0BAVMMQwZjHDMHMwgT
	+CHMKgykTFUOMViMGMx4BAVOBM2MEEwYzF4MFUxVDBTMWQwdjBFMGQyqDkxhjCzN9Q1uDBRMKAQJT
	+gRJzBBMFUwRDgURDF1OBBmMMMwalQydjFgCdC4Rrk0yhF45hhFEqRIEWpQERjU6MOokcgV5ggV6B
	+LIZ1GB6nKxTFH5MHii0gmCW7FWaBD6R2gkuMX4Eog3+lZSOcgWGCCLg4vWpCDYRVHJx6GpJVH4R4
	+iYNJG5ByK4JwP7oKmgGZgTqLJh2cfZ5ytjWUC40GfLChOIE2rBuBTgeiaRaKEIoBlRC7x4M/qR6f
	+T4xdIIEHlBUynh2EVxiIZpk/GRXHkx4NgQCemCdvtZMso0WBHoFIG4EIEfpmDIJq
	#1 2019-03-07T18:27:57Z pgess
	+1sPEAAAB/zEAgm7+QQAkgUCBAnN0aXB0byBtYWtoaWdobnRoZWwnZWNvbmEgZXhhY2hhcmxseXOF
	+DxOHP0MPU4MJIw9jhDtDJlMEUwczMkMZAQRjBVMGUw8jCQEGQxxjCjMiIwRDGGMIMwQzClMGEwRT
	+gS0jBkMT3WMFgwZjHRMLYwxDKFMaYwi7uBMEM4EbIwQzggYBAVN6AQFjChMJM1lDBAEDEwQjBCME
	+kwQzggIBAhMUQxFTCjMK6DMEMwVTBQEDEwVDBgEBYwdTCwECM2ZDQpMUEwRTGEODEFNMYx4zBDNP
	+U4dgQw0TCUMEMwRTGzOEekPJKQCFEIdCE78xgxiEPIQLLAk2k1eMSiuWKBgrDLBlJB6KSwqDSYRR
	+ELIqgS2TYoxapCWOQS0cLCCfPpowhC0Qn3uBIIIIfJITFoUkCbwTvTFtnwuEPFoWgjGRWKgFgUeZ
	+Po4/k1ixOwYeaaSGfF8dgxJNh0MgUZJnihaEDJ5IoksfhHw=
	?>
	\ No newline at end of file
	diff --git a/documentation/index.xml b/documentation/index.xml
	index 7e573d3..8c227b4 100644
	--- a/documentation/index.xml
	+++ b/documentation/index.xml
	@@ -1,338 +1,425 @@
	<?xml version="1.0" encoding="UTF-8"?>
	<chapter version="5.1" xmlns="http://docbook.org/ns/docbook"
	xmlns:xlink="http://www.w3.org/1999/xlink"
	xmlns:xila="http://www.w3.org/2001/XInclude/local-attributes"
	xmlns:xi="http://www.w3.org/2001/XInclude"
	xmlns:trans="http://docbook.org/ns/transclusion"
	xmlns:svg="http://www.w3.org/2000/svg"
	xmlns:m="http://www.w3.org/1998/Math/MathML"
	xmlns:html="http://www.w3.org/1999/xhtml"
	xmlns:db="http://docbook.org/ns/docbook">
	<?xxe-sn 2b06cb2u4g0 1?>

	<title><?xxe-sn 2b06cb2u4g0 2?>Xreate Manual</title>

	<para><?xxe-sn 2b06cb2u4g0 6?>Xreate is an open source general purpose high
	level programming language designed to write efficient and safe computer
	programs.</para>

	<para><?xxe-sn 2b06cb2u4g0 8?>Here "high level" is all about a developer
	- oriented side focused on an ability to easily write, read, as well as adapt
	- software to a constantly changing environment or business goals. In this
	- respect, any software product can be evaluated on the basis of three
	+ oriented side focused on an ability to easily write, read, reuse, as well as
	+ adapt software to a constantly changing environment or business goals. In
	+ this respect, any software product can be evaluated on the basis of three
	dimensions: efficiency, safety, and flexibility. Unfortunately, those
	properties are proved to be largely contradictory, for it is manageable to
	write either efficient (yet unsafe) or safe (yet impractical) code, but not
	both. Thus, the ultimate goal of the language is to allow developers to
	produce code that would have all these properties at the same time. Blending
	features of seemingly incompatible programming paradigms is a basis of
	Xreate's design principles.</para>

	<para><?xxe-sn 2b06cb2u4g0 7?>To achieve the aforementioned design goals,
	Xreate consists of three distinctive layers:</para>

	<itemizedlist>
	<?xxe-sn 2b06cb2u4g0 e?>

	<listitem>
	<?xxe-sn 2b06cb2u4g0 f?>

	<para><?xxe-sn 2b06cb2u4g0 g?><link xlink:href="/d/syntax/"><?xxe-sn 2b06cb2u4g0 o?>Brute</link>.
	The lowest layer is called <emphasis><?xxe-sn 2b06cb2u4g0 p?>Brute
	</emphasis>— this is code that is intended to be actually compiled. Code
	on this level implements actual software functionality. It resembles the
	usual imperative languages' apparatus and consists of executable
	instructions such as arithmetic, branching, input / output, etc.</para>
	</listitem>

	<listitem>
	<?xxe-sn 2b06cb2u4g0 i?>

	<para><?xxe-sn 2b06cb2u4g0 j?><link xlink:href="/d/transcend/"><?xxe-sn 2b06cb2u4g0 q?>Transcend</link>.
	Brute alone is not enough to constitute a full-fledged language since
	code requires various non-executable metadata to express developer's
	intents, check correctness, validity and perform other types of
	analyses. In Xreate everything of this sort belongs to a declarative
	type layer called <emphasis><?xxe-sn 2b06cb2u4g0 s?>Transcend</emphasis>.
	Transcend is a logic reasoner that is appropriate to do management-type
	work — it analyzes, oversees and controls Brute by guiding compilation
	process. More precisely, everything on this level, logic or transcend
	facts and rules, is gathered and sent to an external logic solver to
	make solutions that are brought back in order to guide compilation.
	Unlike usual static analysis tools, Transcend directly controls
	compilation(see <link xlink:href="#basic-example"><?xxe-sn 2dc49lhpp1c 4?>Basic
	Example</link>) and able to make decisions even based on data available
	only at runtime(see <link
	xlink:href="/d/transcend/late-transcend/"><?xxe-sn 2dc49lhpp1c 5?>Late
	Transcend</link>)</para>
	</listitem>

	<listitem>
	<?xxe-sn 2b06cb2u4g0 l?>

	<para><?xxe-sn 2b06cb2u4g0 m?><link
	xlink:href="/d/concepts/interpretation/"><?xxe-sn 2b06cb2u4g0 r?>Interpretation</link>.
	There is also <emphasis><?xxe-sn 2b06cb2u4g0 t?>Interpretation</emphasis>
	— the intermediate level resembling dynamically typed languages that is
	used as a contact point and interpreter between Brute and
	Transcend.</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 2b06cb2u4g0 u?>On a syntactic level, Xreate is a procedural
	language with extensive use of <emphasis><?xxe-sn 2b06cb2u4g0 v?><link
	xlink:href="/d/transcend/"><?xxe-sn 2b06cb2u4g0 w?>annotations</link></emphasis>
	— arbitrary unconstrained metadata that a software developer can attach to
	different language constructs, variables and code blocks. Annotations are
	completely invisible for the compiler proper and used by Transcend more as a
	suggestion conveying additional information.</para>

	<remark><?xxe-sn 2ccp2iy80zj 1td6aqezxvj7l?>"a different language
	constructs": если подразумевается "конструкции разных языков", тогда лучше
	"different languages' constructs". Если конструкции языка, в целом, то тогда
	артикль a не нужен</remark>

	<para><?xxe-sn 2da0r0b6680 2?>There are several extensions already
	implemented to give a feeling what does this structure can be used for.
	<link xlink:href="/d/concepts/containers/"><?xxe-sn 2da0r0b6680 3?>Containers</link>
	chapter describes that it is possible to reason about and automatically
	choose the most appropriate data structure's implementation depending on how
	it is used in the code. Look at the example below:</para>

	<programlisting><?xxe-sn 2da0r0b6680 4?>x = [1, 2, 3]:: [int].</programlisting>

	<para><?xxe-sn 2da0r0b6680 5?>Container <code><?xxe-sn 2da0r0b6680 6?>x</code>
	does not have well defined implementation just yet. Only by looking how it
	is used throughout the code, the compiler is able to decide how exactly to
	store container's data.</para>

	<para><?xxe-sn 2da0r0b6680 7?>Interaction of different components and joint
	use of external resources is covered by <link
	xlink:href="/d/exploitation/"><?xxe-sn 2da0r0b6680 8?>Exploitation</link>:</para>

	- <programlisting><?xxe-sn 2da0r0b6680 9?>dataA = readFromFile("/some/file"):: string. //here a file is accessed for the very first time
	-dataB = readFromFile("/some/file"):: string. //this is the last time the file is accessed</programlisting>
	+ <programlisting><?xxe-sn 2da0r0b6680 9?>logger = createFileLogger("/some/file"):: Logger.
	+...
	+
	+write(logger, "First log entry").
	+...
	+
	+write(logger, "Last log entry").</programlisting>

	<para><?xxe-sn 2da0r0b6680 a?>Exploitation reasoning allows to determine
	when it is the <emphasis><?xxe-sn 2dc0uidlnnk 1?>first</emphasis>,
	- <emphasis><?xxe-sn 2dc0uidlnnk 2?>last</emphasis> access to a file, in other
	- words, infers access order. As a result, using the data it is possible to
	- automatically initialize / destruct related resources.</para>
	+ <emphasis><?xxe-sn 2dc0uidlnnk 2?>last</emphasis> access to resources such
	+ as files, in other words, it infers access order. As a result it is possible
	+ to automatically initialize / destruct related resources. Unlike RAII, an
	+ another related technique, Exploitation is reserved to manage resources
	+ usage that spans across different parts of a program: modules, plugins,
	+ etc.</para>

	<para><?xxe-sn 2dc0uidlnnk 8?><link
	xlink:href="/d/virtualization/"><?xxe-sn 2dc0uidlnnk 4?>Virtualization</link>
	- reasoning enables access control <emphasis><?xxe-sn 2dc0uidlnnk 5?>if and
	- when it is needed only</emphasis>. Example:</para>
	+ reasoning also helps to work with external resources by enabling access
	+ control <emphasis><?xxe-sn 2dc0uidlnnk 5?>if and when it is needed
	+ only</emphasis>. Example:</para>

	<programlisting><?xxe-sn 2dc0uidlnnk 6?>openFile("/some/file"):: string; assign_sizo(zoneA).
	openFile("/some/file"):: string; assign_sizo(zoneB).</programlisting>

	<para><?xxe-sn 2dc0uidlnnk 7?>If the compiler recognizes file access from
	the different zones, as in this example, it applies an appropriate
	virtualization strategy enough to ensure that instructions that belong to
	different zones do not interfere with each other.</para>

	<para><?xxe-sn 2cdtco54w00 3?>Unlike "pure", academic languages, Xreate
	targets safe and reliable usage of effectful computations such as IO that is
	covered above as well as mutable structures described in the <link
	xlink:href="/d/communication/"><?xxe-sn 2b3f3osfk74 l?>Communication</link>
	chapter.</para>

	<para><?xxe-sn 2dc49lhpp1c 2?>Note, that the described extensions are not
	part of the compiler and developers can write their own custom transcend
	rules to cover other aspects.</para>

	<section>
	<?xxe-sn 2b06cb2u4g0 3?>

	<title><?xxe-sn 2b06cb2u4g0 4?>Basic Example</title>

	<para><?xxe-sn 2b06cb2u4g0 5?>To demonstrate what Xreate is all about,
	basic example is given below:</para>

	<programlisting xml:id="Example_1"><?xxe-sn 2b06cb2u4g0 x?>name="tests/introduction.cpp: Introduction.Doc_Example_1", lines=15
	guard:: iAmVeryFast
	{
	- div = function(a:: float, b:: float):: float
	+ div = function(a:: int, b:: int):: int
	{
	a / b
	}
	}

	guard:: iAmVerySafe
	{
	- div = function(a:: float, b:: float):: float
	+ div = function(a:: int, b:: int):: int
	{
	- if ( b == (0::float)):: float {0::float} else {a / b}
	+ if ( b == 0 ):: int { zeroDivisionErrCode() } else { a / b }
	}
	}

	-test = function:: float; entry; iAmVerySecure
	+test = function:: int; entry; iAmVerySecure
	{
	div(10, 5)
	}</programlisting>

	<para><?xxe-sn 2b06cb2u4g0 y?>Here entry point of the program is a
	function <code><?xxe-sn 2b06cb2u4g0 z?>test</code> recognized so by the
	compiler because of annotation <code><?xxe-sn 2b06cb2u4g0 10?>entry</code>
	in its signature. There are also two functions with the same name
	<code><?xxe-sn 2b06cb2u4g0 11?>div</code> called <emphasis><?xxe-sn 2b06cb2u4g0 12?>specializations</emphasis>.
	Each specialization has a guard that defines a <emphasis><?xxe-sn 2dc49lhpp1c 1?>condition</emphasis>
	that has to be met in order to invoke this particular specialization. In
	the example, specializations of <code><?xxe-sn 2b06cb2u4g0 13?>div</code>
	have <code><?xxe-sn 2b06cb2u4g0 14?>iAmVeryFast</code> and <code><?xxe-sn 2b06cb2u4g0 15?>iAmVerySafe</code>
	guards, respectively. Let's say that a code author writes two
	specializations where the first one is a very fast division
	implementation, while the second one is a very safe division
	implementation since it checks division by zero, being "unacceptably slow"
	due to an extra check instruction, though. This is a basis of <link
	xlink:href="/d/concepts/polymorphism/"><?xxe-sn 2b3f3osfk74 2?>polymorphism</link>
	— client's code <code><?xxe-sn 2b3f3osfk74 3?>test</code> is able to work
	- with any specialization, and compiler must decide which one to invoke with
	- the only hint it has — annotation <code><?xxe-sn 2b3f3osfk74 5?>iAmVerySecure</code>
	+ with any specialization, and the compiler must decide which one to invoke
	+ with the only hint it has — annotation <code><?xxe-sn 2b3f3osfk74 5?>iAmVerySecure</code>
	in the function <code><?xxe-sn 2b3f3osfk74 7?>test</code>'s
	signature.</para>

	<remark><?xxe-sn 2ccp2iy80zj 1td6aqezxvj7n?>"provides two specializations"
	- возможно, лучший вариант "designates/assigns/allocates two
	specializations". Или даже просто specifies/indicates. (PS заменил на
	specifies)</remark>

	<remark><?xxe-sn 2ccp2iy80zj 1td6aqezxvj7m?>"unbearably slow" - я бы
	заменил на более нейтральное "too slow". Unbearable - это скорее об
	ощущениях человека. Или, если под "unbearably" имеется в виду "недопустимо
	медленный", тогда - unacceptably slow.</remark>

	<note>
	<?xxe-sn 2b3f3osfk74 n?>

	<para><?xxe-sn 2b3f3osfk74 o?>All annotations (except <code><?xxe-sn 2b3f3osfk74 m?>entry</code>)
	are custom defined by developer itself.</para>
	</note>

	<para><?xxe-sn 2b3f3osfk74 6?>This is when Transcend comes into play. By
	adding a transcend rule as shown below it is possible to associate
	annotation <code><?xxe-sn 2b3f3osfk74 8?>iAmVerySecure</code> with
	invocation of specialization guarded by <code><?xxe-sn 2b3f3osfk74 9?>iAmVerySafe:</code></para>

	<programlisting xml:id="Transcend_Example_1"><?xxe-sn 2b3f3osfk74 a?>name="tests/introduction.cpp: Introduction.Doc_Example_1", lines=15
	dfa_callguard(SiteInv, iAmVerySafe):-
	dfa_callfn(SiteInv, div);
	SiteInv = s(_, _, ScopeInv);
	cfa_parent(ScopeInv, function(FnInv));
	bind_func(FnInv, iAmVerySecure).</programlisting>

	<para><?xxe-sn 2b3f3osfk74 b?>Transcend rules are written in ASP syntax —
	common syntax to write logic programs. This particular rule reads that for
	any function annotated with <code><?xxe-sn 2b3f3osfk74 c?>iAmVerySecure</code>,
	certain specialization <code><?xxe-sn 2b3f3osfk74 d?>iAmVerySafe</code> is
	chosen for <code><?xxe-sn 2b3f3osfk74 e?>div</code> invocation.</para>

	<note>
	<?xxe-sn 2b3f3osfk74 p?>

	<para><?xxe-sn 2b3f3osfk74 q?>In this example an appropriate
	specialization is statically resolved, so the other specialization isn't
	even compiled.</para>

	<remark><?xxe-sn 2ccp2iy80zj 1td6aqezxvj7o?>the, потому что их всего
	две.</remark>
	</note>

	<para><?xxe-sn 2b3f3osfk74 f?>By providing custom rules it is possible to
	implement any polymorphism strategy, be it performed statically or
	dynamically. The example demonstrates basic workflow: Transcend gathers
	available information about a program such as annotations and using custom
	rules makes a decision to guide compilation process, particularly by
	selecting appropriate specializations as in the above example.</para>
	</section>

	<section>
	<?xxe-sn 2fchdmt7vgg 1?>

	- <title><?xxe-sn 2fchdmt7vgg 2?>More Advanced Example: Intentions</title>
	+ <title><?xxe-sn 2fchdmt7vgg 2?>More Advanced Example</title>

	- <para><?xxe-sn 2fchdmt7vgg 3?>Suppose we write a program to prepare a web
	+ <para><?xxe-sn 2fchdmt7vgg 3?>Suppose we write a program to generate a web
	page consisting of several blocks(e.g. a header, a footer) constructed
	independently by different parts of our program. In order to organise the
	- code, we express our intention that all the blocks should be sent to a
	- client in a very specific order: first a header, then a body and footer,
	- as below:</para>
	+ code, we express our <emphasis><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8v?>intention</emphasis>
	+ that all blocks should be sent to a client in a very specific order: first
	+ a header, then a body and footer, as below:</para>

	<programlisting xml:id="ExampleEov_1_Expectation"><?xxe-sn 2fchdmt7vgg 4?>name="tests/exploitation.cpp: Exploitation.Doc_ExampleEov_1", lines=15
	eov_expect(
	webpage, header, body; %we expect body to be sent after header
	webpage, body, footer %.. and footer after body
	).</programlisting>

	<para><?xxe-sn 2fchdmt7vgg 5?>This is similar to <link
	xlink:href="/d/exploitation/"><?xxe-sn 2fchdmt7vgg a?>Exploitation</link>:
	we are working with the external resource <code><?xxe-sn 2fchdmt7vgg b?>webpage</code>
	and want to take into account an exact order of resource exploiting
	operations. Then, we write code like this:</para>

	<programlisting><?xxe-sn 2fchdmt7vgg c?>send("Header"):: Content; eov_checkpoint(webpage, header).</programlisting>

	<para><?xxe-sn 2fchdmt7vgg d?>We mark the operations we are interesting in
	as <emphasis><?xxe-sn 2fchdmt7vgg e?>checkpoints</emphasis>(here
	- <code><?xxe-sn 2fds09lgw74 1?>header</code> is the name of the checkpoint
	+ <code><?xxe-sn 2fds09lgw74 1?>header</code> is the name of a checkpoint
	and <code><?xxe-sn 2fds09lgw74 3?>webpage</code> is the resource the
	checkpoint refers to) and want to know are checkpoints executed in the
	expected(as defined above) order.</para>

	<para><?xxe-sn 2fchdmt7vgg f?>If it so happens that these blocks are
	constructed in the correct order in our program we <emphasis><?xxe-sn 2fchdmt7vgg 6?>may</emphasis>
	send them immediately. Otherwise, we must cache already constructed
	content till a whole page is generated to ensure correctness. In other
	words, clearly, there is an opportunity for optimizations for caching has
	- memory overhead and delays response latency as well. We write two
	- implementations <code><?xxe-sn 2fchdmt7vgg 7?>immediate_output</code> and
	- <code><?xxe-sn 2fchdmt7vgg 8?>cached_output</code> each for the
	+ not only memory overhead but delays response latency(time before the first
	+ block is sent) as well. We write two implementations <code><?xxe-sn 2fchdmt7vgg 7?>immediate_output</code>
	+ and <code><?xxe-sn 2fchdmt7vgg 8?>cached_output</code> each for the
	corresponding case:</para>

	<programlisting xml:id="ExampleEov_1_Specializations"><?xxe-sn 2fchdmt7vgg 9?>name="tests/exploitation.cpp: Exploitation.Doc_ExampleEov_1", lines=15
	//type to store either sending error code or cached content
	Content = type variant {
	errcode:: int,
	message:: string
	}.

	//Send immediately:
	guard:: immediate_output
	{
	send = function(content:: string):: Content
	{
	errcode(printf("%s", content))
	}
	}

	//Cache content to send it later:
	guard:: cached_output
	{
	send = function(content:: string):: Content
	{
	message(content)
	}
	}</programlisting>

	<para><?xxe-sn 2fchdmt7vgg g?>These implementations should be registered
	for the compiler to know which one to use:</para>

	<programlisting xml:id="ExampleEov_1_Registration"><?xxe-sn 2fchdmt7vgg h?>name="tests/exploitation.cpp: Exploitation.Doc_ExampleEov_1", lines=15
	eov_analysis(
	success, immediate_output;
	fail, cached_output
	).</programlisting>

	<para><?xxe-sn 2fchdmt7vgg i?>Predicate <code><?xxe-sn 2fchdmt7vgg j?>eov_analysis</code>
	compares actual checkpoints execution order with the expected one and
	chooses either of two implementations depending on the result. This way,
	it is guarantied that immediate sending is chosen only if it is safe to do
	so to avoid unnecessary caching.</para>

	<para><?xxe-sn 2fchdmt7vgg k?>Thus we can safely change and adapt our
	program knowing that clients always receive web page's content in the
	correct order by automatically employing the most efficient content
	delivery strategy depending on particular circumstances.</para>
	</section>
	+
	+ <section>
	+ <?xxe-sn 2fs1xxghz93 -wunr7fl0rw8u?>
	+
	+ <title><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8t?>Differences from other
	+ languages</title>
	+
	+ <para><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8s?>it is convenient to talk about
	+ <emphasis><?xxe-sn 2fs1xxghz93 -wunr7fl0rw88?>intentions</emphasis> in
	+ order to outline a vast landscape of programming languages and point out
	+ the place of Xreate on it, i.e. to compare languages on a basis do they
	+ allow to express a developer's intentions along with raw code that can be
	+ used on many occasions, e.g. to validate code's correctness. Traditionally
	+ type system is used to declare intentions. At closer look, types in
	+ (imperative) statically typed languages contain information as
	+ follows:</para>
	+
	+ <itemizedlist>
	+ <?xxe-sn 2fs1xxghz93 -wunr7fl0rw8q?>
	+
	+ <listitem>
	+ <?xxe-sn 2fs1xxghz93 -wunr7fl0rw8p?>
	+
	+ <para><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8o?>Intentions, such as "that
	+ variable is a string". </para>
	+ </listitem>
	+
	+ <listitem>
	+ <?xxe-sn 2fs1xxghz93 -wunr7fl0rw8n?>
	+
	+ <para><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8m?>Usage patterns. A new code
	+ should play nicely with the rest of a program, e.g. if a program works
	+ with Unicode, a new string variable should be also of Unicode
	+ type.</para>
	+ </listitem>
	+
	+ <listitem>
	+ <?xxe-sn 2fs1xxghz93 -wunr7fl0rw8l?>
	+
	+ <para><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8k?>Platform constraints, e.g.
	+ if a platform supports wide strings natively, a new string variable
	+ should also be a wide string.</para>
	+ </listitem>
	+ </itemizedlist>
	+
	+ <para><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8j?>In this regard, in general,
	+ statically typed languages are <emphasis><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8i?>overconstrained</emphasis>,
	+ they require developers to provide more information then they intend to.
	+ This generally hinders code reuse and adaptation; to work on a new
	+ platform, code requires porting: a process of re-expressing underlying
	+ intentions once again with the new platform's constraints. </para>
	+
	+ <para><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8h?>On the other side, dynamically
	+ typed languages in this regard are <emphasis><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8g?>underconstrained</emphasis>,
	+ since they do not allow to express all desirable intentions. This leads to
	+ a disastrous inefficiency and code fragility because any errors can be
	+ caught only at runtime. </para>
	+
	+ <para><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8f?>OOP languages are hugely
	+ successful among other reasons because they provide <emphasis><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8e?>classes</emphasis>
	+ to more finely express intentions, e.g. <code><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8d?>String</code>,
	+ <code><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8c?>UnicodeString</code>,
	+ <code><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8b?>Utf8String</code> with exact
	+ behaviour being hidden in implementation details.</para>
	+
	+ <para><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8a?>Xreate in its turn offers
	+ annotations for developers to express intentions, e.g. <code><?xxe-sn 2fs1xxghz93 -wunr7fl0rw87?>string;i_dont_need(cow)</code>
	+ (copy-on-write implementation). Annotations alone is not enough to fully
	+ determine necessary types thus the compiler finishes them by looking at
	+ usage patterns along with platform properties in order to infer most
	+ efficient implementations.</para>
	+
	+ <para><?xxe-sn 2fs1xxghz93 -wunr7fl0rw86?>Also there is an area beyond
	+ type systems capabilities, since types are designed to express intentions
	+ only about data flow. However as shown in the previous example it is also
	+ useful to express intentions about program structure properties, such as
	+ operations order. </para>
	+ </section>
	</chapter>
	diff --git a/documentation/manual.json b/documentation/manual.json
	index 1ca4a56..df326dd 100644
	--- a/documentation/manual.json
	+++ b/documentation/manual.json
	@@ -1,36 +1,36 @@
	{
	"book": "Xreate Manual",
	"pages":
	[
	{"title": "Basics", "pages": [
	{"title": "Introduction", "slug": "/", "filename": "index.xml.remarkup", "subtitle": "General information about Xreate"},
	{"title": "Build and Run", "slug": "build/", "filename": "build.xml.remarkup", "subtitle": "Getting started"},
	{"title": "Syntax", "slug": "syntax/", "filename": "syntax.xml.remarkup", "subtitle": "Xreate syntax in detail"},
	- {"title": "Modules", "slug": "syntax/modules/", "filename": "modules.xml.remarkup", "subtitle": "How to reuse and combine existing code in Xreate"}
	+ {"title": "Modules", "slug": "syntax/modules/", "filename": "modules.xml.remarkup", "subtitle": "Reuse and combine existing code in Xreate"}
	]},

	{"title": "Transcend", "pages": [
	{"title": "Overview", "slug": "transcend/", "filename": "transcend.xml.remarkup", "subtitle": "Declarative level of Xreate"},
	- {"title": "Late Transcend", "slug": "transcend/late-transcend/", "filename": "latetranscend.xml.remarkup", "subtitle": "Reasoning is able to work at runtime"}
	+ {"title": "Late Transcend", "slug": "transcend/late-transcend/", "filename": "latetranscend.xml.remarkup", "subtitle": "Reasoning at runtime"}
	]},

	{"title": "Concepts", "pages": [
	- {"title": "Polymorphism", "slug": "concepts/polymorphism/", "filename": "polymorphism.xml.remarkup", "subtitle": "Let logic inference choose how program would behave at runtime"},
	- {"title": "Context", "slug": "concepts/context/", "filename": "context.xml.remarkup", "subtitle": "How to capture and use information about control flow and hierachy within program"},
	+ {"title": "Polymorphism", "slug": "concepts/polymorphism/", "filename": "polymorphism.xml.remarkup", "subtitle": "Rules to configure and adjust program behaviour"},
	+ {"title": "Context", "slug": "concepts/context/", "filename": "context.xml.remarkup", "subtitle": "Use the information about control flow and code hierachy"},
	{"title": "Interpretation", "slug": "concepts/interpretation/", "filename": "interpretation.xml.remarkup", "subtitle": "Compile time computations"}
	]},

	{"title": "Extensions", "pages": [
	- {"title": "Containers", "slug": "concepts/containers/", "filename": "containers.xml.remarkup", "subtitle": "Automatic inference about the most apporpriate container implementation"},
	- {"title": "Communication", "slug": "communication/", "filename": "communication.xml.remarkup", "subtitle": "Safe usage of mutable as well as global variables"},
	- {"title": "Exploitation", "slug": "exploitation/", "filename": "exploitation.xml.remarkup", "subtitle": "Shared usage of the external resources - initialization and finalization"},
	+ {"title": "Containers", "slug": "concepts/containers/", "filename": "containers.xml.remarkup", "subtitle": "Automatic inference of the most apporpriate container implementation"},
	+ {"title": "Communication", "slug": "communication/", "filename": "communication.xml.remarkup", "subtitle": "Safe usage of mutable and global variables"},
	+ {"title": "Exploitation", "slug": "exploitation/", "filename": "exploitation.xml.remarkup", "subtitle": "Shared usage of the external resources: initialization and finalization"},
	{"title": "Virtualization", "slug": "virtualization/", "filename": "virtualization.xml.remarkup", "subtitle": "Controls access to the external resources or different program's components"}
	]},

	{"title": "Transcend APIs", "pages": [
	{"title": "AST API", "slug": "transcend/ast-api/", "filename": "ast-api.xml.remarkup", "subtitle": ""},
	{"title": "Latex API", "slug": "transcend/latex-api/", "filename": "latex-api.xml.remarkup", "subtitle": ""},
	{"title": "Modules API", "slug": "transcend/modules-api/", "filename": "modules-api.xml.remarkup", "subtitle": ""}
	]}
	]
	}

No OneTemporaryActions

File Metadata

View Options

Event Timeline

No OneTemporary
Actions