No OneTemporary
Actions

Subscribers

None

File Metadata

Created: Sun, Feb 15, 5:14 PM

View Options

	diff --git a/documentation-tools/doc-converter/doctl b/documentation-tools/doc-converter/doctl
	index 1de5c7d..b236c91 100755
	--- a/documentation-tools/doc-converter/doctl
	+++ b/documentation-tools/doc-converter/doctl
	@@ -1,61 +1,62 @@
	#!/bin/bash
	PANDOC=/opt/pandoc/dist-newstyle/build/x86_64-linux/ghc-8.6.4/pandoc-2.7.1/x/pandoc/build/pandoc/pandoc
	REMOTE='xreate@xreate.bigserver'
	DOC_CONTENT=(
	'documentation/Transcend/transcend.xml'
	'documentation/Transcend/ast-api.xml'
	'documentation/Transcend/latetranscend.xml'
	'documentation/Transcend/modules-api.xml'
	'documentation/Transcend/latex-api.xml'
	'documentation/Concepts/interpretation.xml'
	'documentation/Concepts/containers.xml'
	'documentation/Concepts/polymorphism.xml'
	'documentation/Concepts/context.xml'
	'documentation/Syntax/syntax.xml'
	'documentation/Syntax/modules.xml'
	'documentation/virtualization.xml'
	'documentation/exploitation.xml'
	'documentation/communication.xml'
	'documentation/index.xml'
	+ 'documentation/build.xml'
	)
	PWD=`pwd`
	Filename=`realpath $0`

	upload () {
	convert_all /tmp/docs2
	rsync -e 'ssh -p24' -rtvz $Filename $REMOTE:/opt/doctl
	rsync -e 'ssh -p24' -rtvz /tmp/docs2/ $REMOTE:/opt/documentation/
	rsync -e 'ssh -p24' -rtvz $PWD/documentation/manual.json $REMOTE:/opt/documentation/
	}

	convert (){
	SOURCE_FILE=$1
	DEST_FOLDER=$2
	Name=$(basename $SOURCE_FILE)
	sed -e '/<?xxe-revisions/, /?>/ d' -e 's/<?xxe[^?]*?>//g' $SOURCE_FILE \| \
	$PANDOC \
	-f docbook \
	-t $PWD/documentation-tools/doc-converter/remarkup.lua \
	-o $DEST_FOLDER/$Name.remarkup
	}

	convert_all (){
	DEST_FOLDER=$1
	mkdir -p $DEST_FOLDER
	for Chapter in ${DOC_CONTENT[@]}; do
	convert $PWD/$Chapter $DEST_FOLDER
	done
	}

	case $1 in
	convert)
	convert $2 $3
	;;
	convert-all)
	convert_all $2
	;;
	upload)
	upload $2
	;;
	*) echo "usage: $0 convert <SOURCE-FILE> <DEST-FOLDER> \| convert-all <DEST-FOLDER> \| upload";;
	esac
	diff --git a/documentation/Concepts/context.xml b/documentation/Concepts/context.xml
	index 020b673..16a26ec 100644
	--- a/documentation/Concepts/context.xml
	+++ b/documentation/Concepts/context.xml
	@@ -1,304 +1,304 @@
	<?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>

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

	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}
	}

	main = function:: int; 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>
	</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>

	<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>
	</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>
	</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>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 2ahi4rjnvuo u?>Example below</para>

	<programlisting xml:id="ContextPropagation1"><?xxe-sn 2ahi4rjnvuo w?>name = "..."
	//requires 'safe' context
	guard:: safe
	{
	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
	}
	} </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 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>

	<programlisting xml:id="ContextPropagation2"><?xxe-sn 2ahi4rjnvuo 14?>name = "..."
	toSI = function(x:: int):: int
	{ 0 }

	calculate = function(x:: int):: int
	{
	y = toSI(x):: int.
	y
	}

	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>
	</section>

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

	<title><?xxe-sn 2ahi4rjnvuo 1n?>Latex (Late Context)</title>

	<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>,
	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>
	</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>
	</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>
	</listitem>
	</itemizedlist>

	<programlisting xml:id="Latex1"><?xxe-sn 2ahi4rjnvuo 21?>name = "..."
	import raw ("core/control-context.lp").

	compute = function:: int
	{ 0 }

	computeFast = function:: int {
	context:: computation(fast).

	compute()
	}

	computePrecisely = function:: int {
	context:: computation(precise).

	compute()
	}

	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
	}
	}

	case context:: computation(precise) {
	compute = function:: num {
	0
	}
	}

	executeComputation= function:: num {
	compute()
	}

	test = function(cmnd:: num):: num; entry {
	if (cmnd > 0)::num {
	context:: computation(fast).
	executeComputation()

	} else {
	context:: computation(precise).
	executeComputation()
	}
	}</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>
	</section>
	</chapter>
	diff --git a/documentation/Concepts/polymorphism.xml b/documentation/Concepts/polymorphism.xml
	index ccc0819..05619d8 100644
	--- a/documentation/Concepts/polymorphism.xml
	+++ b/documentation/Concepts/polymorphism.xml
	@@ -1,272 +1,272 @@
	<?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 26n42fz1reo 1?>

	<title><?xxe-sn 26n42fz1reo 2?>Polymorphism</title>

	<para><?xxe-sn 2be091dx6gw 1?>See <link
	- xlink:href="/w/syntax#function-specializations"><?xxe-sn 2be091dx6gw 2?>function
	+ xlink:href="/d/syntax/#function-specializations"><?xxe-sn 2be091dx6gw 2?>function
	specializations</link> for syntax.</para>

	<para><?xxe-sn 26n42fz1reo 3?><emphasis><?xxe-sn 26n42fz1reo 4?>Polymorphism</emphasis>
	is an umbrella term to denote a number of techniques across different
	programing paradigms. They all share the same intention to provide the
	ability to easily recombine software components in a different way with as
	little manual work on developer's side as possible. It serves two major
	goals: <emphasis><?xxe-sn 26n42fz1reo 5?>specialization</emphasis>, which
	purports that software initially designed to support a wide range of use
	cases is being configured for a specific case, and <emphasis><?xxe-sn 26n42fz1reo 6?>extension</emphasis>
	– adapting software to an environment and conditions it was not specifically
	designed for.</para>

	<para><?xxe-sn 26n42fz1reo 7?>In course of software engineering evolution, a
	number of polymorphism techniques was proposed and experimented with, all
	suited for different use-cases. Xreate presents a generalized and elegant
	approach that exhaustively covers the wide landscape of polymorphism
	variations.</para>

	<para><?xxe-sn 26n42fz1reo 8?>Polymorphism in Xreate can be applied on two
	levels:</para>

	<itemizedlist>
	<?xxe-sn 26n42fz1reo 9?>

	<listitem>
	<?xxe-sn 26n42fz1reo a?>

	<para><?xxe-sn 26n42fz1reo b?><emphasis><?xxe-sn 26n42fz1reo c?>Functions
	level</emphasis>. Function in Xreate can have multiple
	<emphasis><?xxe-sn 26n42fz1reo d?>specializations</emphasis>, and
	polymorphism is compiler's ability to decide which exactly
	specialization to use depending on various factors</para>
	</listitem>

	<listitem>
	<?xxe-sn 26n42fz1reo e?>

	<para><?xxe-sn 26n42fz1reo f?><emphasis><?xxe-sn 26n42fz1reo g?>Modules
	level</emphasis>. Multiple modules can provide the same service for
	users. <link
	- xlink:href="/w/syntax/modules/#modules-resolution"><?xxe-sn 26n42fz1reo h?>Modules
	+ xlink:href="/d/syntax/modules/#modules-resolution"><?xxe-sn 26n42fz1reo h?>Modules
	Resolution</link> is a process to decide which exactly module to
	use.</para>

	<remark><?xxe-sn 26vapv2jrow pu35zrt1aby9?>По поводу Modules Resolution:
	кажется в предыдущем файле я внес несколько исправлений, добавив
	апостроф после Modules. По грамматическим правилам это верно, но если
	Modules Resolution это устоявшийся термин в твоей документации, то
	возможно лучше без апострофа.</remark>
	</listitem>
	</itemizedlist>

	<section>
	<?xxe-sn 26n42fz1reo i?>

	<title><?xxe-sn 26n42fz1reo j?>Function Level Polymorphism</title>

	<para><?xxe-sn 26n42fz1reo k?>Basic idea is to allow developer to define
	several functions with the same name or, in other words, several
	<emphasis><?xxe-sn 26n42fz1reo l?>specializations</emphasis>. Caller code
	then invokes the necessary function by its shared name, but cannot specify
	a particular specialization directly. The exact specialization to be
	invoked is decided later by a decision process called <emphasis><?xxe-sn 26n42fz1reo m?>polymorphism
	resolution</emphasis> carried out by Transcend. This indirect invocation
	approach gives enough flexibility to use or replace different
	specializations depending on various conditions during compile time as
	well as at runtime.</para>

	<para><?xxe-sn 26n42fz1reo n?>Each specialization must have unique
	<emphasis><?xxe-sn 26n42fz1reo p?>guard</emphasis> (among all
	specializations with the same name) to be discernible from others. To
	summarize, function invocation is a two-layered process, where the client
	code specifies the callee function's shared name, while polymorphism
	resolution specifies specialization guard, if needed.</para>

	<para><?xxe-sn 26n42fz1reo q?>For example, let us assume that we have been
	developing a software program to operate under specified time constraints.
	To model an implementation suitable for real time environment, one
	specialization of <code><?xxe-sn 26n42fz1reo r?>crucialOperation</code> is
	defined with <code><?xxe-sn 26n42fz1reo s?>env(realtime)</code> guard,
	i.e. it satisfies some fixed execution time constraints. Caller
	<code><?xxe-sn 26n42fz1reo t?>main</code> specifies just a function name
	<code><?xxe-sn 26n42fz1reo u?>crucialOperation</code> thus delegating the
	decision in respect of guard to polymorphism resolution done elsewhere,
	based on the environment's constraints the code is executed in.</para>

	<programlisting xml:id="FnLvlPoly_1"><?xxe-sn 26n42fz1reo v?>name="tests/polymorph.cpp: Polymorphs.Doc_FnLvlPoly_1"
	guard:: env(realtime)
	{
	crucialOperation = function:: int
	{ 0 }
	}

	main = function:: int; entry
	{
	crucialOperation()
	} </programlisting>
	</section>

	<section>
	<?xxe-sn 26n42fz1reo w?>

	<title><?xxe-sn 26n42fz1reo x?>Polymorphism Resolution</title>

	<synopsis><?xxe-sn 26n42fz1reo y?>SYNTAX:
	dfa_callguard(//call-site-ref//, //guard//)</synopsis>

	<itemizedlist>
	<?xxe-sn 26n42fz1reo z?>

	<listitem>
	<?xxe-sn 26n42fz1reo 10?>

	<para><?xxe-sn 26n42fz1reo 11?><emphasis><?xxe-sn 26n42fz1reo 12?>call-site-ref</emphasis>
	reference to a call site in AST</para>
	</listitem>

	<listitem>
	<?xxe-sn 26n42fz1reo 13?>

	<para><?xxe-sn 26n42fz1reo 14?><emphasis><?xxe-sn 26n42fz1reo 15?>guard</emphasis>
	resolved function specialization guard</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 26n42fz1reo 16?>When compiler encounters function
	invocation that has several specializations it refers to the table
	<code><?xxe-sn 26n42fz1reo 17?>dfa_callguard</code> to find out which
	specialization to call. It must have an entry with appropriate
	<code><?xxe-sn 26n42fz1reo 18?>guard</code> for every invocation site
	<code><?xxe-sn 26n42fz1reo 19?>call-site-ref</code> of a polymorphic
	function. Polymorphism resolution is a process of filling out
	<code><?xxe-sn 26n42fz1reo 1a?>dfa_callguard</code> for the compiler based
	on custom Transcend rules reflecting one or another polymorphism
	strategy.</para>
	</section>

	<section>
	<?xxe-sn 26n42fz1reo 1b?>

	<title><?xxe-sn 26n42fz1reo 1c?>Late Polymorphism</title>

	<para><?xxe-sn 26n42fz1reo 1d?>Late Polymorphism is an extension to allow
	polymorphism resolution to be based on data known only at runtime, i.e.
	resolve function specializations dynamically. The Idea is to use Late
	Transcend to access runtime data. See <link
	- xlink:href="/w/transcend/latetranscend"><?xxe-sn 26n42fz1reo 1e?>Late
	+ xlink:href="/d/transcend/latetranscend/"><?xxe-sn 26n42fz1reo 1e?>Late
	Transcend</link> for details.</para>

	<para><?xxe-sn 26n42fz1reo 1f?>Example below demonstrates <code><?xxe-sn 26n42fz1reo 1g?>test</code>
	invoking polymorphic function <code><?xxe-sn 26n42fz1reo 1h?>compute</code>:</para>

	<programlisting xml:id="LatePoly_1"><?xxe-sn 26n42fz1reo 1i?>name="tests/polymorph.cpp: Polymorphs.Doc_LatePoly_1"
	Strategy = type variant {fast, precise}.

	guard:: fast
	{
	compute = function:: int
	{0}
	}

	guard:: precise
	{
	compute = function:: int
	{1}
	}

	test = function(s:: Strategy; alias(strategy)):: int; entry
	{
	switch late (s):: int
	{
	compute():: int; guardalias(strategy)
	}
	}</programlisting>

	<para><?xxe-sn 26n42fz1reo 1j?>Function <code><?xxe-sn 26n42fz1reo 1k?>compute</code>
	has two specializations, <code><?xxe-sn 26n42fz1reo 1l?>fast</code> and
	<code><?xxe-sn 26n42fz1reo 1m?>precise</code>. We see that <code><?xxe-sn 26n42fz1reo 1n?>test</code>
	gets parameter <code><?xxe-sn 26n42fz1reo 1o?>s</code> that dictates exact
	strategy to use. Clearly, resolution should work dynamically to deal with
	cases like this, for not only the value of the parameter <code><?xxe-sn 26n42fz1reo 1p?>s</code>
	is unknown at the compile time, but also it can change with each
	<code><?xxe-sn 26n42fz1reo 1q?>test</code> execution.</para>

	<para><?xxe-sn 26n42fz1reo 1r?>Operation <code><?xxe-sn 2be091dx6gw 3?>switch late</code>
	is compiled into several branches, two in this case, each branch executing
	appropriate <code><?xxe-sn 26n42fz1reo 1s?>compute</code> specialization.
	The correct branch is executed depending on the current <code><?xxe-sn 26n42fz1reo 1t?>s</code>
	value. Custom annotations <code><?xxe-sn 26n42fz1reo 1u?>alias(Alias)</code>
	and <code><?xxe-sn 26n42fz1reo 1v?>guardalias(Alias)</code> are used to
	assign an alias in order to specify which parameter to use as basis for
	resolution.</para>
	</section>

	<section>
	<?xxe-sn 26n42fz1reo 1w?>

	<title><?xxe-sn 26n42fz1reo 1x?>Auto Expansion of Late Parameters</title>

	<para><?xxe-sn 26n42fz1reo 1y?>In the previous example, operation
	<code><?xxe-sn 2be091dx6gw 4?>switch late</code> was used to facilitate
	calling of a polymorphic function with late polymorphism resolution. It is
	not that convenient to wrap each invocation using <code><?xxe-sn 2be3dypnsao 1?>switch
	late</code> whenever we need to call a late polymorphic function. Compiler
	uses the late parameter auto expansion technique in order to specifically
	handle cases like this.</para>

	<para><?xxe-sn 26n42fz1reo 1z?>If compiler discovers that <code><?xxe-sn 26n42fz1reo 20?>late(dfa_callguard())</code>
	entry exists for current invocation, and it does not have enclosing
	<code><?xxe-sn 2be091dx6gw 5?>switch late</code> already, compiler
	automatically generates different branches that invoke relevant
	specializations and transfers control to a branch depending on the late
	parameter's value. In other words, invocation is implicitly wrapped into
	<code><?xxe-sn 2be091dx6gw 6?>switch late</code> if needed.</para>
	</section>
	</chapter>
	<?xxe-revisions
	#5 2019-03-07T17:53:18Z pgess
	#4 2019-03-07T17:09:57Z pgess
	1sPEAAABzxMAJM5rAAEQDVNzwgojBRMMU4Zt1VMFY4VXAMcao16ePpdskCeHIA==

	#3 2019-01-04T15:38:33Z Acer2
	1sPEAAABzmsAiGDYGwCCDIQFgkZQbGVhc2YgYWJzLiBhPz4iRCIgLbXQs9C40YDRg4DQtbW+0YK4
	uNC80YMg0YE/INCV0L+y0Yuy0LDRgNC40LDQs9C00LCw0LfRjCAiImE3eGd5eTVxejFzIi4uLrWM
	uNGA0Ysg0LfRgdGMIHNpYXJ5LmNhbWJyaWRnZWl1YT8+MSkgIr27vdGP0L280Yu10LSHuNGCILXR
	hSDRitC10LqFIC0sIEUsIEm1LYHQuLq4PyDQlrXRg4e7sNGFICLRh7IiuiDRjy4gMikgIkmBsLjQ
	uyy+t9Cw0LOyINCx0YPQujsgIiKz0LTQvNCzu9GOLiDQob7Rhy240Le+0Y4/INCiZSJpbmNvYXRl
	L2k/c4QIE45PQ4pOAQX4IwYTQRMLIwRDBTMUwVMXAQNTh0czCGMEEw1DY2MoAQVDF4MIAQP6QwQB
	CDMEAQNTBEMFpMGTBIMFAQFjCDMFAQEjI1MGAQcTBSMGMwUBBDMHy8EBCVMEYwYBBjMMEwWpAQRD
	KwEBQwszPXMFU4o+AQEzhjlDh3mDEgEKYyEBARMEMwTCUwQjBaSl0wEHQwQBBRME0+ABDWMFkwtD
	EIMMUw1DDEOFH3MMEwRDBWOEBnMMM4EjUwhDNnMMAQH3kwVjFCMoAQdDG3MMkwcjBbwTBQEBIwZT
	BMGy9TMFMwS3MwQjBa/z5RMEAQQTBAEGYwUBA1MJAQNTBAEDYwsjBBMEIwUjCyMEYwUjBoMFAQH8
	IwRDBSMIAQMTCAEBcwkjCZMFAQEzCwEEIwUTBKSTBAECUwUBAYMEIwQzBQEBkwYBAVMEAQYTBUME
	QwQBAhMGAQtTGnMMkweTBP8zBUMEAQGDBZMFUwQjBgEDQw5zC6/vEwSTDSMEQwuTBJMFIwSDBAEF
	EwWvMwQBByMEkwQBAzMXsdOyIwUBAjMEAQITBBMEIwQBAxMEAQQjCDME/FMEAQIzBiMEIwUBAZMG
	AQOTBiMEIxYBARMEIwcjBUMFYwaTBxMFAQJDDAEEYwozBpMFkwojCkMGAQIzCIMKAQQTBAEFEwYB
	ASMMUwtDCwCFLo5QnyKmP4QagzStfxayRJgykRuBaoJbmmyLVYUQiDKRdaeBOX6BN1Q0lGaBAsu5
	jGBmRgmVfg2IbBozUA8MF5YOlgSONyaBH5R5ikGGbwccilegeYZhi0OcE5VWlGmBRwQeBIQXCuqD
	TLSpbocwQIiHa5tuhVuIgySgN4EtiKZvOWiNLKRviCypSiOUNw0BgkKoKEKBOz+pGiCpeI14PU2V
	WZVDQ7ImmRGCBqkklWKpdlOOToEEjlq5tHdjgQOqbpRgyW0fCKtNlgWVIDwruY9XBndRlQE5HJRX
	tiWILDl3gRQxoDwHrHY9iINMw5R4eZEMTdQ+g2pWliEtX6xRgLRhUAmCMoRZgQGXMZUQTJRchFmB
	eYIRYSatHROvpIJ6hGCUZ4VQaYFnTs2XJoEGHxVWxoF3tCmBIDWIZoENrimgZqUU
	#2 2018-12-16T15:30:15Z Acer2
	1sPEAAAB2BsAgXPOcAAKgQdbY29wQydieVN0b3OxNROBBUOOYwEDUwcTBlMPQwljCjMdUw0TBFMF
	Qw4zEkNYU4FMAQFjDhMGMxBTgT9jQxMFMxZDCWMqU3FDEjMMUywzOgEBQy4BAiMNUwkTBEMFQwRj
	CFMQMwwBARMEQwgBAjMXQwtjBRMEYyNDgSVTIHMMY4ERgwRDIGMNMxdzDEMfEwtjCwCxNoEIkAWI
	B45zHIVityM0iTGtdA0SF4F9gVGkQxcUgUOIIUSBLqtxSnWHXB4uPIEkQJhGrCGIYZB9hXSBPocd
	gWQHgXDEYJpJDVOBJpwsSYEZIRCcI6tXh3Q=
	#1 2018-12-12T21:49:13Z pgess
	1sPEAAABznAAggjHRwASgRVaZW4sY29uY3JlLWEnLiBFIGluc4RwE2lDCFNHYwtjIDNeAQJTCWME
	UxxDF7FTDQEGIwYzCGMEMz4BATOBLZMKQ3BjOjOCUgEBQ0gjBZMNU4NVQwxTglljJTMIAQEjBEMG
	UwlDGQEDYzZThERjeAEBMxEBAkMHQxZjH1MEkw0jCjMLUw9TBVM2MwVjB0MPEwdTPzOBS0MGU25j
	BWNWQxVTDFMnMztDpRQAhHJtC2dGC4Mmjj57HpM2I4kUkV4wHUFygTlyPoJRkBMvW2mGZoJdJqN4
	MoYBFg04hEV5kXwbGpodL6RIhEqYYZRYghyRSDgOhkAuQoFMCZJzdVqNVR8rgxU=
	-?>
	\ No newline at end of file
	+?>
	diff --git a/documentation/Syntax/modules.xml b/documentation/Syntax/modules.xml
	index 6fee31f..e4d93f2 100644
	--- a/documentation/Syntax/modules.xml
	+++ b/documentation/Syntax/modules.xml
	@@ -1,408 +1,408 @@
	<?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 26n42fz1reo 21?>

	<title><?xxe-sn 26n42fz1reo 22?>Modules</title>

	<para><?xxe-sn 26n42fz1reo 23?>Xreate offers <emphasis><?xxe-sn 26n42fz1reo 24?>modules</emphasis>
	as a way to organize and reuse source code. For simplicity's sake, it is
	implemented as one file — one module, with one to one correspondence.</para>

	<para><?xxe-sn 26n42fz1reo 25?>Modules often require prior compilation of
	other modules for correct work. This leads to a problem of
	<emphasis><?xxe-sn 26n42fz1reo 26?>resolution</emphasis> where the required
	module is located, determine exact module's filename, especially as modern
	software products tend to incorporate a complicated and volatile file
	structure depending on configuration and platform to build. The common
	practice is to rely on build configuration tools to provide exact path to
	each module.</para>

	<remark><?xxe-sn 26r2dlt35rk pu35zrt1abya?>Не вполне понимаю смысл фразы "a
	resolution where the required module is located". Принятие решения о том,
	где будет располагаться какой модуль? Тогда может лучше будет так: "This
	leads to a problem of resolution where to locate which module". Как в этом
	примере: "Therefore tools for choosing where to locate which types of
	production like this method will become increasingly useful". Или выяснение
	того, где находится нужный модуль?</remark>

	<para><?xxe-sn 26n42fz1reo 27?>For this reason Xreate interferes as little
	as possible with the resolution. The language does not allow for a module to
	specify a path directly, be it a relative or an absolute path in respect to
	other required modules. Also the compiler does not search for modules in any
	predefined list of directories, and does not assume anything about project's
	file structure. It expects the resolution information to have been already
	fully predefined before the start of the compilation process.</para>

	<remark><?xxe-sn 26r2dlt35rk pu35zrt1abyb?>1. Если resolution - это процесс,
	то перед словами обозначающими какой-либо процесс, как правило, артикли не
	ставятся (исключение - если речь идет о каком-то конкретном процессе,
	например, "Dune2: The building of a dynasty"). А неопределенный артикль
	совершенно исключен в этом случае. 2. "The language does not support for a
	module" - возможные варианты замены: "The language offers no instruments
	allowing a module to...", "The language has no means allowing a module
	to...". 3. "Does not search for modules in some..." - в вопросительных
	предложениях и при отрицании употребляется местоимение "any" вместо
	"some".</remark>

	<para><?xxe-sn 26n42fz1reo 28?>However, the compiler features some optional
	built-in functionality to facilitate resolution. It is the very type of a
	problem the transcend level is excellently suited for. It is modeled after a
	<emphasis><?xxe-sn 26n42fz1reo 29?>supply and demand</emphasis> approach and
	lets modules to declare what they <emphasis><?xxe-sn 26n42fz1reo 2a?>provide</emphasis>
	and what they <emphasis><?xxe-sn 26n42fz1reo 2b?>require</emphasis>,
	expressed by annotations. Compiler then tries to satisfy the requirements
	and find a match. Alternatively, external tools can always be used.</para>

	<section>
	<?xxe-sn 26n42fz1reo 2c?>

	<title><?xxe-sn 26n42fz1reo 2d?>Module Headers</title>

	<synopsis><?xxe-sn 26n42fz1reo 2e?>SYNTAX:
	module [:: //annotations-list// ] (Full form)
	{
	//module-statement//...
	}</synopsis>

	<synopsis><?xxe-sn 26n42fz1reo 2f?>module :: //annotations-list// . (Simplified form)</synopsis>

	<synopsis><?xxe-sn 26n42fz1reo 2g?>//module-statement// ::=
	\| require ( //annotation// ). (1)
	\| discover ( //path// ). (2)
	\| controller (//path//). (3)</synopsis>

	<itemizedlist>
	<?xxe-sn 26n42fz1reo 2h?>

	<listitem>
	<?xxe-sn 26n42fz1reo 2i?>

	<para><?xxe-sn 26n42fz1reo 2j?><code><?xxe-sn 26n42fz1reo 2k?>annotations-list</code>
	List of annotations delimited by semicolon</para>
	</listitem>

	<listitem>
	<?xxe-sn 26n42fz1reo 2l?>

	<para><?xxe-sn 26n42fz1reo 2m?><code><?xxe-sn 26n42fz1reo 2n?>annotation</code>
	Any valid transcend expression</para>
	</listitem>

	<listitem>
	<?xxe-sn 26n42fz1reo 2o?>

	<para><?xxe-sn 26n42fz1reo 2p?><code><?xxe-sn 26n42fz1reo 2q?>path</code>
	Absolute or relative path to controller</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 26n42fz1reo 2r?>Xreate recognizes a number of module
	management statements. Those statements should be located in a specific
	section <code><?xxe-sn 26n42fz1reo 2s?>module {...}</code> of a source
	code which is called <emphasis><?xxe-sn 26n42fz1reo 2t?>module
	header</emphasis>. Module can have several headers. All headers gathered
	from a single file are combined into one before actual processing.</para>

	<note>
	<?xxe-sn 26n42fz1reo 2u?>

	<para><?xxe-sn 26n42fz1reo 2v?>Modules' processing happens before
	compilation. This means that any data produced in course of compilation
	is inaccessible at this stage</para>
	</note>
	</section>

	<section>
	<?xxe-sn 26n42fz1reo 2w?>

	<title><?xxe-sn 26n42fz1reo 2x?>Requesting Modules</title>

	<para><?xxe-sn 26n42fz1reo 2y?>Statement <code><?xxe-sn 26n42fz1reo 2z?>require(..)</code>
	expresses which modules are required for correct compilation.</para>

	<programlisting xml:id="Requesting_Modules_1"><?xxe-sn 26n42fz1reo 30?>name="tests/modules.cpp: Modules.Doc_Requesting_Modules_1"
	module {
	require(logger).
	}</programlisting>

	<para><?xxe-sn 26n42fz1reo 31?>In this example a module in question
	requires some other module that <emphasis><?xxe-sn 26n42fz1reo 32?>provides</emphasis>
	a feature called <code><?xxe-sn 26n42fz1reo 33?>logger</code>. There is no
	way to specify the direct location of the external module. Instead, the
	"main" module expresses a requirement in an abstract form as a
	propositional expression which is later used by the resolution to find the
	exact match.</para>

	<programlisting xml:id="Requesting_Modules_2"><?xxe-sn 26n42fz1reo 34?>name="tests/modules.cpp: Modules.Doc_Requesting_Modules_2"
	module{require(stringslib).}
	processString = function(a:: string):: string
	{
	someStrFunc(a)
	}

	module{require(mathlib).}
	processNumber = function(a:: num):: num
	{
	someMathFunc(a)
	}</programlisting>

	<para><?xxe-sn 26n42fz1reo 35?>The above example demonstrates usage of
	several headers in one file. It is particularly useful in situations where
	a developer finds it convenient to place requirements beside the actual
	code that uses them. This way one can easily spot the requirements that
	are no more needed. After all, code locality improves readability.</para>
	</section>

	<section>
	<?xxe-sn 26n42fz1reo 36?>

	<title><?xxe-sn 26n42fz1reo 37?>Module Annotations</title>

	<para><?xxe-sn 26n42fz1reo 38?>A module can declare an additional
	information for various uses. This is expressed by annotations located in
	the header. They are called 'module annotations'. For instance, module
	annotations can be used by module resolution to find modules that satisfy
	requirements of other modules.</para>

	<programlisting xml:id="ModuleAnnotations_1"><?xxe-sn 26n42fz1reo 39?>name="tests/modules.cpp: Modules.Doc_ModuleAnnotations_1"
	module:: status(obsolete).</programlisting>

	<para><?xxe-sn 26n42fz1reo 3a?>The example shows a module that declares
	its status. It can be used by resolution to select the most appropriate
	module out of a number of candidates. One way to view annotations used by
	resolution is to treat them as something that module <emphasis><?xxe-sn 26n42fz1reo 3b?>provides</emphasis>.</para>

	<note>
	<?xxe-sn 26n42fz1reo 3c?>

	<para><?xxe-sn 26n42fz1reo 3d?>There are no predefined module
	annotations, and developers can place arbitrary information
	there.</para>
	</note>
	</section>

	<section>
	<?xxe-sn 26n42fz1reo 3e?>

	<title><?xxe-sn 26n42fz1reo 3f?>Modules Resolution</title>

	<para><?xxe-sn 26n42fz1reo 3g?>Modules resolution is a process to find
	exact modules' locations that match requests. Compiler does not perform a
	search of modules in any predefined directories, and it does not assume
	anything about project's file structure. Compiler, in order to allow a
	developer to determine it independently, refers to two transcend
	tables:</para>

	<remark><?xxe-sn 26r2dlt35rk pu35zrt1abyd?>Вот я и дошел до ответа что
	такое resolution :) Оставляю предыдущие комменты для истории.</remark>

	<synopsis><?xxe-sn 26n42fz1reo 3h?>SYNTAX:
	modules_resolution(//request//, //module-resolved//). (1)
	modules_resolution(//request//, //module-resolved//, //module-context//). (2)</synopsis>

	<itemizedlist>
	<?xxe-sn 26n42fz1reo 3i?>

	<listitem>
	<?xxe-sn 26n42fz1reo 3j?>

	<para><?xxe-sn 26n42fz1reo 3k?><emphasis><?xxe-sn 26n42fz1reo 3l?>request</emphasis>
	annotation used in statement <code><?xxe-sn 26n42fz1reo 3m?>request(...)</code></para>
	</listitem>

	<listitem>
	<?xxe-sn 26n42fz1reo 3n?>

	<para><?xxe-sn 26n42fz1reo 3o?><emphasis><?xxe-sn 26n42fz1reo 3p?>module-resolved</emphasis>
	Path or identifier of a module that matches request</para>
	</listitem>

	<listitem>
	<?xxe-sn 26n42fz1reo 3q?>

	<para><?xxe-sn 26n42fz1reo 3r?><emphasis><?xxe-sn 26n42fz1reo 3s?>module-context</emphasis>
	Path or identifier of a module that requires other module</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 26n42fz1reo 3t?>These tables contain resolved modules for
	all possible requests. Form (1) contains requests that should always be
	resolved to the same module regardless of where module is requested. Form
	(2) contains such requests for which resolution depends on requester
	<emphasis><?xxe-sn 26n42fz1reo 3u?>module-context</emphasis>. In other
	words, difference between forms (1) and (2) is that form (2) takes into
	account not only <emphasis><?xxe-sn 2be3ap8an7k 1?>what</emphasis>(parameter
	<code><?xxe-sn 2be3ap8an7k 2?>request</code>) is requested but also
	<emphasis><?xxe-sn 2be3ap8an7k 5?>where from</emphasis>(parameter
	<code><?xxe-sn 2be3ap8an7k 4?>module-context</code>) it is
	requested.</para>

	<programlisting xml:id="ModulesResolution_1"><?xxe-sn 26n42fz1reo 3v?>name="tests/modules.cpp: Modules.Doc_ModulesResolution_1"
	modules_resolution(numlib, "/path/to/numlib").
	modules_resolution(strings, "/path/to/ansi-lib", "moduleA").
	modules_resolution(strings, "/path/to/utf8-lib", "moduleB"). </programlisting>

	<para><?xxe-sn 26n42fz1reo 3w?>In the above example, compiler would always
	resolve a path to numerical lib(<code><?xxe-sn 26n42fz1reo 3x?>numlib</code>)
	as "/path/to/numlib" (line 1). However, <code><?xxe-sn 26n42fz1reo 3y?>strings</code>
	library would be resolved as "/path/to/ansi-lib" if requested in
	<code><?xxe-sn 26n42fz1reo 3z?>moduleA</code> (line 2) and as
	"/path/to/utf8-lib" if requested in <code><?xxe-sn 26n42fz1reo 40?>moduleB</code>
	(line 3).</para>

	<para><?xxe-sn 26n42fz1reo 41?>When compiler encounters a module request,
	it looks up a <code><?xxe-sn 26n42fz1reo 42?>modules_resolution</code>
	table (either the first or the second one) to find the path to the
	requested module. Tables can be populated by any means, be it transcend
	reasoning or any external tools.</para>

	<note>
	<?xxe-sn 26n42fz1reo 43?>

	<para><?xxe-sn 26n42fz1reo 44?>There is no defined order or priority or
	fall back behavior while looking into tables. If the same request occurs
	in both tables they are considered to be ill-formed</para>
	</note>
	</section>

	<section>
	<?xxe-sn 26n42fz1reo 45?>

	<title><?xxe-sn 26n42fz1reo 46?>Advanced Modules' Resolution</title>

	<para><?xxe-sn 26n42fz1reo 47?>Xreate provides an additional layer – an
	optional helper, to simplify modules management. It introduces two more
	built-in statements that can be used in the module's header:
	<emphasis><?xxe-sn 26n42fz1reo 48?>Discover</emphasis> Statement and
	<emphasis><?xxe-sn 26n42fz1reo 49?>Controller</emphasis> Statement.</para>

	<itemizedlist>
	<?xxe-sn 26n42fz1reo 4a?>

	<listitem>
	<?xxe-sn 26n42fz1reo 4b?>

	<para><?xxe-sn 26n42fz1reo 4c?><emphasis><?xxe-sn 26n42fz1reo 4d?>Discover
	Statement</emphasis> is presented in the form <code><?xxe-sn 26n42fz1reo 4e?>discover
	(<emphasis><?xxe-sn 26n42fz1reo 4f?>path</emphasis>)</code>. It allows
	to specify a directory within which compiler would recursively search
	for all Xreate files and extract module header annotations. It gathers
	information about all found source files.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26n42fz1reo 4g?>

	<para><?xxe-sn 26n42fz1reo 4h?><emphasis><?xxe-sn 26n42fz1reo 4i?>Controller
	Statement</emphasis> is presented in the form <code><?xxe-sn 26n42fz1reo 4j?>controller
	(<emphasis><?xxe-sn 26n42fz1reo 4k?>path</emphasis>)</code> and
	specifies a path to the modules' resolution controller. Controller is
	a file that contains transcend rules in order to process data gathered
	by discovery and populate resolution tables as a result of its
	work.</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 26n42fz1reo 4l?>The below example shows 3 modules:</para>

	<programlisting xml:id="AdvModRes_1"><?xxe-sn 26n42fz1reo 4m?>name="tests/modules.cpp: Modules.Doc_AdvModRes_1"
	//First Module
	module::
	name(testA);
	provide(superService);
	status(needToTestEvenMore).

	//Second Module
	module::
	name(testB);
	provide(superService);
	status(needToTest).

	//Third Module
	module {
	require(superService).
	discover("/modules/path/").
	controller("/path/to/controller").
	}</programlisting>

	<para><?xxe-sn 26n42fz1reo 4n?>Two of the modules offer the same feature
	<code><?xxe-sn 26n42fz1reo 4o?>provide(superSerivce)</code>. The third
	module requires it and specifies a directory in which to look for needed
	files. The controller's task is to populate the resolution table if the
	necessary module is found, and also to choose the appropriate candidate,
	if more than one module offer this service.</para>

	<para><?xxe-sn 26n42fz1reo 4p?>One way to decide what to choose in this
	example is to look at the status of both modules. Let a score be assigned
	to each possible status, e.g. <code><?xxe-sn 26n42fz1reo 4q?>0</code> for
	<code><?xxe-sn 26n42fz1reo 4r?>status(needToTestEvenMore)</code> and
	<code><?xxe-sn 26n42fz1reo 4s?>1</code> for <code><?xxe-sn 26n42fz1reo 4t?>status(needToTest)</code>.
	The controller would then proceed with best scoring module –
	<code><?xxe-sn 26n42fz1reo 4u?>Second Module</code> in this case.</para>
	</section>

	<section>
	<?xxe-sn 26n42fz1reo 4v?>

	<title><?xxe-sn 26n42fz1reo 4w?>See Also</title>

	<para><?xxe-sn 26n42fz1reo 4x?>Transcend: <link
	- xlink:href="/w/transcend/modules-api"><?xxe-sn 26n42fz1reo 4y?>Modules
	+ xlink:href="/d/transcend/modules-api/"><?xxe-sn 26n42fz1reo 4y?>Modules
	API</link></para>
	</section>
	</chapter>
	<?xxe-revisions
	#5 2019-03-07T17:46:08Z pgess
	#4 2019-03-07T17:15:17Z pgess
	1sPEAAAB+GQAiBuBgFEAgQiED4J6LDmwvtC90YDRg9C60Ya0g7DRgLLRgyAoIri4Iikg0YPRh7Vy
	Y6DQsYzQtb4s0LG70LjRhyKyuSK9s9C+0J7Qv9GMuCzRgbgggbXQvC4g0K2A0LbRgCy6hii+tbGL
	j7AstLM/KWU/PiKyILggIqG+0Lmx0Yu60LLQs71mPz7QojIpMyl4b3V0cHOFFBMfryMKQzKxMwlT
	BCMNUwRTBQEBUwQBA0MEAQgTBhMEAQFTB8hDBEMFEwUBATMEUwTjYwQBBlMFAQEzBDME2c2yYwUB
	ATMoE4FKM4dgQ4xFsFOMLWMEM4svUywTKAEBMwYBAUMHMwRTBgECQwYTBFMFQwQzBAEDYwhTDxME
	EwgBAWMHAQFTB74TBUMHMwQBBSMHAQFTBVMEsAECEw0jBVMEpCMEAQNjBQEEEwQBAoMEQwQBApMF
	kwmDBGMXkwpzBYMHQwVjDSMFEwUBAmMOUwWDBMwzBgEBIwSTBRMEAQeDBWMFIwRDBXMFEwYTBAED
	QwSTBXMEAQIzBIMEIwsBAUMFIwUjBgEBIwRDBTMGAQFzBJMTAQEzFyMEIwX4QwQTBa9jBnMFUwVT
	BmMEQwRjBxMF4MgTCgEBgwaDBCMEMwVTBDMFAQJDCGMGgwewrwECEwxjKWObVjNJMwRDDVMhQx4T
	MQEEMzpzBZMEQwZDBEMKMwQjBCMFoyMEIwS8kwQBAzMbEwQBARMKIwYBAyMIUw3NEwZjBOAzBGMF
	MwyDBCMHIwRTBCMJEwqDBMBjEYMEMw1DBCMHIwQTBQECIwcBAVMEEw0zFhMHMwozG1ODNEMJYx0z
	gQMzBmNdQxKDKAEFcwRjC2MGIwRDBCMEUwmTBgECMwSTBgECgydDiwEBAWOERDMFMwQBBBMGM411
	AIUbn26Le4RZuAVgj05TjkWCNoc+rkeLMIoxJoxCiFKBMoo3gUCDeoQSaYYPQgEFhRk+hQ4LhhCB
	bYdkryWMSow1jC+LM4l+iTuDNIRfr3+BG4tkgSKFDyOIV4NllSOTfJlXk2aCSItuiVevCWSDYxUG
	i3cxgW+LKLASi26LHcWvdMlUIplQDZldkmOHVYIJi2iIdxRZgQWFALE+4JRXM4MXgluBPceWV5Uy
	gQ6wrohwSYErrS6CArJ2sxYTBIE3iR2BbWyzFYIsi1azWifeiRyyQi1LI5RShSVYi3kgWQeEYVwv
	AaxqxbRZc452mXKFLJt+f5EIlkNtiXWDWpk3jCGLNYJZgRbSNKBqjB6hPqITh3jhiD2LEopMolWj
	Tn5qizeCXIEIgxqIKmReoRmjSCs0lEcpgjeCPiaBGUeBVKRVlkjVATGOdZhvg2STbyiSBJcFgjeD
	W4MqgQpe/uyEXYMUrDCKVg+GYFStLlR1gkaLAo9djQq/ZoRT

	#3 2018-12-16T14:37:25Z Acer2
	1sPEAAABgYBRAEH+OwABJBYgc7ELE4obIwZDiCZjlyABAVMIMygjFRMHUyODFXMHQ5YwM4wNALFG
	xDiKXIhgg2aXYTG8K0LDKz2WYg==
	#2 2018-12-14T15:41:37Z Acer2
	1sPEAAAB/jsAghD8cQANgRdlLGF1bEV1cCdzIHNheXPMUBMLQx9TmFZTMGMSUwxDBQEBYxAzYEMG
	Q0ITClMEY4F8EwRTcTMVEwZDBVMFY21DgTtzBJMmU1tjCIMIYwtDgQ0BAWMEIwWnEwVDFVMrMwQB
	AWMHMwZDBlODRYNgQyUjEFMIAQJTExMKQxeTFBMGMxAjBRMFU4ErQxxTKVMFAQZjcRMeQ1EjDFMH
	Yw1DBFMTgx4zgjIAhxuZf6wupzyZB59kIgwRjhts0EB7UJlTggxykTMd0lgRdNNWgXHDN6mBYX12
	gR/FGIgKn1iBQawpk3gIhw8UqWSKHYJlQe9kIYq/HyGOII5HJ4EvHhYv3XaBEoskOWiaTg32NA==
	#1 2018-12-12T21:49:18Z pgess
	1sPEAAAB/HIAhU7hUQAogwuCEyfigJRJdC4gRXNpbmN1c3VDTGt3aG9JdCdmdXMgbmVhaXR3aXNl
	bChzhRgBARMZAQNDFBMcU04BAjMXQyNDIFMHYxMBA0MKAQQjBVMW2jMFIwQzMTMGMyUBAVNNQwRD
	FYMcQ0wBAWMdIwYzBWMHEwpjBBMEYwZjDTMIQwmTB0MQgwkzEFMPUx9jBjNDUxdjDhMIMxMjCTMm
	IwoTBDNJ3xMGEwQjBjMKQwZDB0MMUxQTIzOBEVM3YxljIUM9UwdTBGOJNkNOIwZTgV0BAzOBBkMo
	AQITCFOECzNsYwdDUyMGYxATBlMGQwiDBjMLUxBjEDNDQxVTgjEjCGMGQw9jBFMfAQEzFwEBQyMB
	AVMJEwQBBWMGUxYBAlMHEwQzBCMGQwv8MwRzDmOBUxMGYw5DcIMGMw5TdEOBL1NBEwUjBGMdU4Ia
	kwczCCMEIwRDgWszMhMHgwgBAVMEUwljSjMRYxpDBM0TDTMekwljHzOIb2MGUyJjJ1OCKBMEYwQz
	CVMFgw1jFUNsU4IWYziDBjMJMwxDBmM7AQFDCVMHEwUzCWMFMwdDNlMHYwgzFhMOQwozG2OZWQCF
	Gh6DdYILUpUjOJIzKxaNdBAFiiaoNzCBHTEqpTkO9YU0iACTGLJogQiRJIEGinIJCBCxHesoHR2H
	eCKDUSZHJJJBmW2MfYgIggCZVEODYI5tiCSgfKtKjhUVCQeEID2BFqI/USVBPQeJOq0qVoFhgQeZ
	WjmEDYIxdZlXbYkDk0sTCRkNExJHhWy0NoI1Dm4WISuVMIUhoGBAgmKEX7k3mBZco0GXNucjg2SB
	WxEJm1KBBnuBMY5IjGROH+SgJIhHiQuJTYFskiQJgWUclDO2cBOsG2ubfilThR2BRqcOkQSJHYNH
	hQagLKxdizP+nxAXbYMNCYNoSoFeDk0Non6RaaVXkEutJgSuCD+gFYILjEtN
	-?>
	\ No newline at end of file
	+?>
	diff --git a/documentation/Syntax/syntax.xml b/documentation/Syntax/syntax.xml
	index 209abbb..2f3e370 100644
	--- a/documentation/Syntax/syntax.xml
	+++ b/documentation/Syntax/syntax.xml
	@@ -1,959 +1,959 @@
	<?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 5b?><informaltable>
	<?xxe-sn 26yv439af40 5c?>

	<tgroup cols="3">
	<?xxe-sn 26yv439af40 5d?>

	<tbody>
	<?xxe-sn 26yv439af40 5e?>

	<row>
	<?xxe-sn 26yv439af40 5f?>

	<entry><?xxe-sn 26yv439af40 5g?>Literals, Expressions, Basic
	Statements</entry>

	<entry><?xxe-sn 26yv439af40 5h?>Annotations</entry>

	<entry><?xxe-sn 26yv439af40 5i?>Intrinsics: query</entry>
	</row>

	<row>
	<?xxe-sn 26yv439af40 5j?>

	<entry><?xxe-sn 26yv439af40 5k?>Identifiers, Code Blocks</entry>

	<entry><?xxe-sn 26yv439af40 5l?>Branch Statements</entry>

	<entry><?xxe-sn 26yv439af40 5m?>Interfaces: Extern-C</entry>
	</row>

	<row>
	<?xxe-sn 26yv439af40 5n?>

	<entry><?xxe-sn 26yv439af40 5o?>Functions</entry>

	<entry><?xxe-sn 26yv439af40 5p?>Loops</entry>

	<entry><?xxe-sn 26yv439af40 5q?>Other: Transcend, Versions</entry>
	</row>

	<row>
	<?xxe-sn 26yv439af40 5r?>

	<entry><?xxe-sn 26yv439af40 5s?>Types</entry>

	<entry><?xxe-sn 26yv439af40 5t?>Variants</entry>

	<entry><?xxe-sn 26yv439af40 5u?></entry>
	</row>
	</tbody>
	</tgroup>
	</informaltable></para>

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

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

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

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

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

	<para><?xxe-sn 26yv439af40 60?>Order in which identifiers are defined
	does not influence computation order. Identifiers are computed in order
	based on dependencies between expressions. Order in which identifiers
	are defines reflects personal preferences and what is convenient for a
	developer.</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 26yv439af40 6g?>5,
	"Nimefurahi kukujua"</code></entry>
	</row>

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

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

	<entry><?xxe-sn 26yv439af40 6j?>Record is a collection of elements
	of different types — <code><?xxe-sn 26yv439af40 6k?>{year = 1934,
	month = "april"}</code>. List is a collection of elements of the
	same type without keys — <code><?xxe-sn 26yv439af40 6l?>{16, 8,
	3}</code>. Range of elements — <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 26yv439af40 6p?>+, -, *, /</code></entry>
	</row>

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

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

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

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

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

	<entry><?xxe-sn 26yv439af40 6z?><emphasis><?xxe-sn 26yv439af40 70?>index</emphasis>
	operation to access individual elements of a list or a record.
	Example: <code><?xxe-sn 26yv439af40 71?>colors = {"Green",
	"Blue"}::[string]. color = colors[0]:: string.</code> Record's
	element access: <code><?xxe-sn 26yv439af40 72?>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).</code></entry>
	</row>
	</tbody>
	</tgroup>
	</informaltable>
	</section>

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

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

	<para><?xxe-sn 26yv439af40 7d?>Block is a list of expressions delimited by
	period. It has a <emphasis><?xxe-sn 26yv439af40 7e?>body</emphasis> - main
	expression and optionally some identifier definitions.</para>

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

	<para><?xxe-sn 26yv439af40 7g?>Code block consists of <emphasis><?xxe-sn 26yv439af40 7h?>body
	expression</emphasis> and optional set of assignments to define
	identifiers used in body expression. Block's computation is defined as a
	result of associated body expression's computation. Identifiers are
	computed before expressions they are used in.</para>

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

	a + b:: int
	}</programlisting>

	<para><?xxe-sn 26yv439af40 7j?>Above is an example of code block which
	have <code><?xxe-sn 26yv439af40 7k?>a+b</code> as a body expression. In
	this case body depends on identifiers <code><?xxe-sn 26yv439af40 7l?>a</code>,
	<code><?xxe-sn 26yv439af40 7m?>b</code> so compiler computes both of them
	beforehand.</para>

	<para><?xxe-sn 26yv439af40 7n?>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?>Identifier gets computed only if it's
	required(even transitively) by 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 function</para>
	</listitem>

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

	<para><?xxe-sn 26yv439af40 81?><emphasis><?xxe-sn 26yv439af40 82?>argument</emphasis>
	formal parameter. 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 and returning value 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 a function
	<code><?xxe-sn 26yv439af40 8e?>sum</code>. It takes two arguments and
	returns their sum. Also it defines several annotations. First annotation
	<code><?xxe-sn 26yv439af40 8f?>entry</code> has a special meaning — it
	depicts entry point or main function in a program. Second annotation
	<code><?xxe-sn 26yv439af40 8g?>status(needs_review)</code> is a
	demonstration that developers can annotate function using custom
	annotations to express different 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 by annotation</para>
	</listitem>

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

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

	<para><?xxe-sn 26yv439af40 8s?>Xreate allows several functions to share
	the same name. In which case they are called <emphasis><?xxe-sn 26yv439af40 fk?>
	specializations</emphasis>. This is syntactic foundation for
	<emphasis><?xxe-sn 26yv439af40 8u?>function level polymorphism</emphasis>,
	i.e. ability for compiler to decide which exactly function is called out
	of several options. Polymorphism resolution can happen during compilation
	or at run-time.</para>

	<para><?xxe-sn 26yv439af40 8v?>Functions with the same name, i.e.
	different specializations should have additional unique identifiers called
	<emphasis><?xxe-sn 26yv439af40 8w?>guards</emphasis>. When function is
	actually called it's expected that resolution is already done at some
	point before and supplies correct guard to uniquely specify which exactly
	specialization to call.</para>

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

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

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

	<para><?xxe-sn 26yv439af40 90?>See <link
	- xlink:href="/w/transcend/ast-api#function-s-specializatio"><?xxe-sn 26yv439af40 91?>API</link>
	+ xlink:href="/d/transcend/ast-api/#function-s-specializatio"><?xxe-sn 26yv439af40 91?>API</link>
	to get more information on how guards are processed</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?><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 <emphasis><?xxe-sn 26yv439af40 9a?>condition</emphasis> evaluation
	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>'s
	result is used 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?>SWITCH statement evaluation's result is
	that of branch whose <emphasis><?xxe-sn 26yv439af40 9s?>guard</emphasis>
	matches <emphasis><?xxe-sn 26yv439af40 9t?>condition</emphasis>.</para>

	<para><?xxe-sn 26yv439af40 9u?>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 {"Strange.. Don't know this month"}.</programlisting>
	</section>
	</section>

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

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

	<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 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 result of previous iteration or <emphasis><?xxe-sn 26yv439af40 aa?>init-value</emphasis>
	during first iteration. Result of the <emphasis><?xxe-sn 26yv439af40 ab?>loop-body</emphasis>
	evaluation is used as <emphasis><?xxe-sn 26yv439af40 ac?>accumulator</emphasis>'s
	next iteration value and as overall loop statement result after the last
	iteration.</para>

	<para><?xxe-sn 26yv439af40 ad?>This notation does not have termination
	condition. Compiler relies on loop body's fixed point in order to decide
	when to interrupt loop. Let's consider example:</para>

	<programlisting xml:id="LoopStatement1"><?xxe-sn 26yv439af40 ae?>COUNTEREXAMPLE, name="tests/ast.cpp: AST.Doc_LoopStatements"
	//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). While
	iterating accumulator <code><?xxe-sn 26yv439af40 ag?>x</code> assumes
	values as follows: 2, 3, 4, 5, 6, 6 ... After it founds first perfect
	number any further iteration do not change result anymore since there is
	no increment and it continues to test the same number again and again.
	Obviously, <code><?xxe-sn 26yv439af40 ah?>x=6</code> is a fixed point in
	this example. There is no point to continue going through further
	iterations once fixed point is evaluated and hence loop can be safely
	interrupted.</para>

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

	<programlisting xml:id="LoopStatement2"><?xxe-sn 26yv439af40 al?>name="tests/ast.cpp: AST.Doc_LoopStatements"
	//loop exits after 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 compiler able to recognize
	when fixed point is reached to exit loop. After loops is done
	<code><?xxe-sn 26yv439af40 an?>answer</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>
	to iterate through</para>
	</listitem>

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

	<para><?xxe-sn 26yv439af40 ax?><emphasis><?xxe-sn 26yv439af40 ay?>element</emphasis>
	identifier that assumes value of currently processed 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 with</para>
	</listitem>

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

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

	<para><?xxe-sn 26yv439af40 b9?>Iterates over <emphasis><?xxe-sn 26yv439af40 ba?>list</emphasis>
	in order to accumulate result by applying <emphasis><?xxe-sn 26yv439af40 bb?>loop-body</emphasis>
	transformation to each <emphasis><?xxe-sn 26yv439af40 bc?>element</emphasis>
	and intermediate <emphasis><?xxe-sn 26yv439af40 bd?>accumulator</emphasis>.
	Overall loop value is a accumulator's value after the last iteration. If
	fixed point is found an execution terminates earlier.</para>

	<para><?xxe-sn 26yv439af40 be?>Example shows code excerpt that looks for
	a minimal element in the given list(and less then 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>
	to iterate through</para>
	</listitem>

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

	<para><?xxe-sn 26yv439af40 bp?><emphasis><?xxe-sn 26yv439af40 bq?>element</emphasis>
	identifier that assumes value of 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>

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

	<para><?xxe-sn 26yv439af40 bw?><emphasis><?xxe-sn 26yv439af40 bx?>loop-body</emphasis></para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 26yv439af40 by?>Iterates over input <emphasis><?xxe-sn 26yv439af40 bz?>list</emphasis>
	and applies <emphasis><?xxe-sn 26yv439af40 c0?>loop-body</emphasis>
	transformation to each element. Result is a list that consists of all
	transformed elements.</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>

	<para><?xxe-sn 26yv439af40 c2?>Example demonstrates creating
	<code><?xxe-sn 26yv439af40 c3?>even_number</code> list by multiplying by
	2 every element of <code><?xxe-sn 26yv439af40 c4?>odd_numbers</code>.</para>
	</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 26yv439af40 cd?>

	<entry><?xxe-sn 26yv439af40 ce?><code><?xxe-sn 26yv439af40 cf?>num</code></entry>

	<entry><?xxe-sn 26yv439af40 cg?><code><?xxe-sn 26yv439af40 ch?>i32</code>
	alias. Reserved as a placeholder for auto detected appropriate
	either integral of floating-point type</entry>
	</row>

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

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

	<entry><?xxe-sn 26yv439af40 cl?><code><?xxe-sn 26yv439af40 cm?>i32</code>
	alias. Reserved as a placeholder for auto detected appropriate
	integral type</entry>
	</row>

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

	<entry><?xxe-sn 26yv439af40 co?><code><?xxe-sn 26yv439af40 cp?>float</code></entry>

	<entry><?xxe-sn 26yv439af40 cq?>Double precision floating-point
	number</entry>
	</row>

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

	<entry><?xxe-sn 26yv439af40 cs?><code><?xxe-sn 26yv439af40 ct?>bool</code></entry>

	<entry><?xxe-sn 26yv439af40 cu?>Boolean type</entry>
	</row>

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

	<entry><?xxe-sn 26yv439af40 cw?><code><?xxe-sn 26yv439af40 cx?>i8,
	i32, i64</code></entry>

	<entry><?xxe-sn 26yv439af40 cy?>Signed integers. 8, 32, 64 bit
	wide respectively</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?>Pointer to a null terminated ANSI
	char string. Reserved for auto detected most appropriate string
	type.</entry>
	</row>

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

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

	<entry><?xxe-sn 26yv439af40 d6?>Unspecified type. Example
	<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?><code><?xxe-sn 26yv439af40 dg?>[
	<emphasis><?xxe-sn 26yv439af40 dh?>element-type</emphasis>
	]</code></entry>

	<entry><?xxe-sn 26yv439af40 di?>List of elements of the same type
	<emphasis><?xxe-sn 26yv439af40 dj?>element-type</emphasis>.
	Example: <code><?xxe-sn 26yv439af40 dk?>[int]</code> - list of
	<code><?xxe-sn 26yv439af40 dl?>int</code>'s</entry>
	</row>

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

	<entry><?xxe-sn 26yv439af40 dn?><code><?xxe-sn 26yv439af40 do?>{<emphasis><?xxe-sn 26yv439af40 dp?>key</emphasis>::
	<emphasis><?xxe-sn 26yv439af40 dq?>type</emphasis>,
	...}</code></entry>

	<entry><?xxe-sn 26yv439af40 dr?>List of elements of different type
	possibly with named keys. Examples: <code><?xxe-sn 26yv439af40 ds?>{int,
	string}</code>, <code><?xxe-sn 26yv439af40 dt?>{name::string,
	age::int}</code></entry>
	</row>

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

	<entry><?xxe-sn 26yv439af40 dv?><code><?xxe-sn 26yv439af40 dw?>variant
	{<emphasis><?xxe-sn 26yv439af40 dx?>option</emphasis> ::
	(<emphasis><?xxe-sn 26yv439af40 dy?>type</emphasis>, ...},
	...}</code></entry>

	<entry><?xxe-sn 26yv439af40 dz?>Holds a single element of type of
	one out of number of options. 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?><code><?xxe-sn 26yv439af40 e3?>slave
	<emphasis><?xxe-sn 26yv439af40 e4?>identifier</emphasis></code></entry>

	<entry><?xxe-sn 26yv439af40 e5?>Type determined by Transcend.
	Example: <code><?xxe-sn 26yv439af40 e6?>slave
	unit_test</code></entry>
	</row>

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

	<entry><?xxe-sn 26yv439af40 e8?><code><?xxe-sn 26yv439af40 e9?><emphasis><?xxe-sn 26yv439af40 ea?>compound-type</emphasis>
	[ <emphasis><?xxe-sn 26yv439af40 eb?>key</emphasis>
	]</code></entry>

	<entry><?xxe-sn 26yv439af40 ec?>Accessing elements of compound
	type. Example: <code><?xxe-sn 26yv439af40 ed?>Bio = type
	{birth_year:: int, name:: string}. Year = type
	Bio[birth_year].</code></entry>
	</row>
	</tbody>
	</tgroup>
	</informaltable>

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

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

	<para><?xxe-sn 26yv439af40 eg?>Example:</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</programlisting>
	</section>

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

	<title><?xxe-sn 26yv439af40 ej?>Variants and SWITCH VARIANT
	Instruction</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 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 condition withing case
	branches.</para>
	</listitem>

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

	<para><?xxe-sn 26yv439af40 et?><emphasis><?xxe-sn 26yv439af40 eu?>guard</emphasis>
	name of 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>
	block of code to execute in case of matched variant. Content is
	accessible by using alias Within the branch .</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 26yv439af40 ey?>Sometimes it is useful for a variable to
	have value of different types depending on some conditions, in other words
	it has <emphasis><?xxe-sn 26yv439af40 ez?>variant type</emphasis>.</para>

	<para><?xxe-sn 26yv439af40 f0?>Let's consider example with variable
	<code><?xxe-sn 26yv439af40 fi?>month</code> of variant type
	<code><?xxe-sn 26yv439af40 fj?>Month</code>:</para>

	<programlisting xml:id="Variants1"><?xxe-sn 26yv439af40 f3?>name="tests/ast.cpp: AST.Doc_Variants"
	Month = type variant {
	MonName :: {string},
	MonNumber:: {int}
	}.

	test = function:: Month
	{
	month = MonName("April"):: Month.
	month
	}</programlisting>

	<para><?xxe-sn 26yv439af40 f4?>Variable <code><?xxe-sn 26yv439af40 f5?>month</code>
	holds value of either <code><?xxe-sn 26yv439af40 f6?>string</code> or
	<code><?xxe-sn 26yv439af40 f7?>int</code> type. Value is not accessible
	directly. It should be <emphasis><?xxe-sn 26yv439af40 f8?>unwrapped</emphasis>
	before using. Xreate supports <code><?xxe-sn 26yv439af40 f9?>switch variant</code>
	instruction for this operation.</para>

	<para><?xxe-sn 26yv439af40 fa?>As an example below is function
	<code><?xxe-sn 26yv439af40 fb?>nextMonth</code>'s definition:</para>

	<programlisting><?xxe-sn 26yv439af40 fc?>nextMonth = function(month:: Month):: Month
	{
	switch variant(month):: Month
	case (MonName)
	{
	//
	}
	case (MonNumber)
	}</programlisting>
	</section>
	</chapter>
	<?xxe-revisions
	#3 2019-02-23T12:37:01Z pgess
	#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/Transcend/ast-api.xml b/documentation/Transcend/ast-api.xml
	index 5fae63b..c757ee2 100644
	--- a/documentation/Transcend/ast-api.xml
	+++ b/documentation/Transcend/ast-api.xml
	@@ -1,495 +1,495 @@
	<?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">
	<title>AST API</title>

	<para>In order to reason about program, code model is translated into form
	suited for processing by Transcend. Translation details are described
	below.</para>

	<section>
	<title>Expression Annotations: 'bind'</title>

	<synopsis>SYNTAX:
	bind(//symbol-ref//, //annotation//)</synopsis>

	<itemizedlist>
	<listitem>
	<para><emphasis>symbol-ref</emphasis> reference to the expression or
	identifier</para>
	</listitem>

	<listitem>
	<para><emphasis>annotation</emphasis> expression's annotation</para>
	</listitem>
	</itemizedlist>

	<para>Declares expression's annotations.</para>

	<para>Example:</para>

	<programlisting xml:id="ExprAnn_1">name="tests/transcend-ast.cpp: ASTCorrespondence.Doc_BasicTests"
	test = function:: int
	{
	x = 5:: int; expected(even_number).

	x
	}</programlisting>

	<para>gets translated into:</para>

	<programlisting xml:id="Output_ExprAnn_1">bind(s(1,-2,0),expected(even_number)) </programlisting>
	</section>

	<section>
	<title>Code Block: 'scope'</title>

	<synopsis>SYNTAX:
	scope(//scope-ref//)</synopsis>

	<itemizedlist>
	<listitem>
	<para><emphasis>scope-ref</emphasis> reference to the code
	block</para>
	</listitem>
	</itemizedlist>

	<para>Declares code block under its unique reference identifier.</para>

	<para>Example:</para>

	<programlisting xml:id="CodeBlock_1">name="tests/transcend-ast.cpp: ASTCorrespondence.Doc_BasicTests"
	test = function:: float
	{
	x = 3:: float.
	y = 8:: float.

	x + y
	}</programlisting>

	<para>Translation result: <code
	xml:id="Output_CodeBlock_1">scope(0)</code></para>
	</section>

	<section>
	<title>Code Block Annotations: 'bind_scope'</title>

	<warning>
	<para>Pending syntax changes</para>
	</warning>

	<synopsis>SYNTAX:
	bind_scope(//scope-ref//, //annotation//, strong) (1)
	bind_scope(//scope-ref//, //annotation//, weak(..)) (2)
	</synopsis>

	<itemizedlist>
	<listitem>
	<para><emphasis>scope-ref</emphasis> child block's reference</para>
	</listitem>

	<listitem>
	<para><emphasis>annotation</emphasis> code block's annotation</para>
	</listitem>
	</itemizedlist>

	<para>Declares code block's annotations called
	<emphasis>context</emphasis>. There are two forms for different context'
	type:</para>

	<itemizedlist>
	<listitem>
	<para><emphasis>strong</emphasis> context known at compile time</para>
	</listitem>

	<listitem>
	<para><emphasis>weak</emphasis> possible context, can't be decided for
	sure at compile time</para>
	</listitem>
	</itemizedlist>

	<para>Example:</para>

	<programlisting xml:id="CodeBlockAnns_1">name="tests/transcend-ast.cpp: ASTCorrespondence.Doc_BasicTests"
	test = function:: float
	{
	context:: arithmetic(fast).

	x = 3:: float.
	y = 8:: float.

	x + y
	}</programlisting>

	<para>Translation's result:</para>

	<programlisting xml:id="Output_CodeBlockAnns_1">bind_scope(0,arithmetic(fast),strong)</programlisting>
	</section>

	<section>
	<title>Code Block Bindings: 'ast_scope_binding'</title>

	<synopsis>SYNTAX:
	ast_scope_binding(//scope-ref//, //binding-id//, //binding-alias//)</synopsis>

	<itemizedlist>
	<listitem>
	<para><emphasis>scope-ref</emphasis> code block's reference</para>
	</listitem>

	<listitem>
	<para><emphasis>binding-id</emphasis> number of code block's
	binding</para>
	</listitem>

	<listitem>
	<para><emphasis>binding-alias</emphasis> name of a binding</para>
	</listitem>
	</itemizedlist>

	<para>Code blocks have zero or more <emphasis>bindings</emphasis>, i.e.
	Identifiers that have special meaning within the block. Predicate declares
	such code block's bindings. Bindings organized into ordered list. Order is
	conveyed by specifying <emphasis>binding-id</emphasis> for each
	<emphasis>binding-alias.</emphasis></para>

	<para>Example:</para>

	<programlisting xml:id="CodeBlockBinds_1">name="tests/transcend-ast.cpp: ASTCorrespondence.Doc_BasicTests"
	test = function:: int
	{
	loop ( 0 -> acc ):: int
	{
	if(acc > 10):: int {acc:: int; final} else {acc + 1}
	}
	}</programlisting>

	<para>Translation result: <code
	xml:id="Output_CodeBlockBinds_1">ast_scope_binding(1,0,"acc")</code></para>
	</section>

	<section>
	<title>Code Block Parents: 'cfa_parent'</title>

	<synopsis>SYNTAX:
	cfa_parent(//scope-ref//, scope(//scope-parent-ref//))</synopsis>

	<itemizedlist>
	<listitem>
	<para><emphasis>scope-ref</emphasis> child block's reference</para>
	</listitem>

	<listitem>
	<para><emphasis>scope-parent-ref</emphasis> parent block's
	reference</para>
	</listitem>
	</itemizedlist>

	<para>Represents nested code blocks structure in terms of
	<emphasis>child-parent</emphasis> relation.</para>

	<para>Example:</para>

	<programlisting xml:id="CodeBlockParents_1">name="tests/transcend-ast.cpp: ASTCorrespondence.Doc_BasicTests"
	test = function:: int
	{
	x = 19:: int.

	if (x>5):: int {x + 1} else {x - 1}
	}</programlisting>

	<para>Translation's result:</para>

	<programlisting xml:id="Output_CodeBlockParents_1">cfa_parent(1, scope(0)).
	cfa_parent(2, scope(0)).</programlisting>
	</section>

	<section>
	<title>Function: 'function'</title>

	<synopsis>SYNTAX:
	function(//fn-name//)</synopsis>

	<itemizedlist>
	<listitem>
	<para><emphasis>fn-name</emphasis> function name</para>
	</listitem>
	</itemizedlist>

	<para>Declares function identified by its name.</para>

	<para>Example:</para>

	<programlisting xml:id="Fn_1">name="tests/transcend-ast.cpp: ASTCorrespondence.Doc_BasicTests"
	test = function:: int {0}</programlisting>

	<para>Translation's result: <code
	xml:id="Output_Fn_1">function(test)</code></para>
	</section>

	<section>
	<title>Function's Annotations: 'bind_func'</title>

	<synopsis>SYNTAX:
	bind_func(//fn-name//, //annotation//)</synopsis>

	<itemizedlist>
	<listitem>
	<para><emphasis>fn-name</emphasis> function's name</para>
	</listitem>
	</itemizedlist>

	<para>Declares function's annotations.</para>

	<para>Example:</para>

	<programlisting xml:id="FnAnns_1">name="tests/transcend-ast.cpp: ASTCorrespondence.Doc_BasicTests"
	test = function:: int; status(obsolete) {0}</programlisting>

	<para>Translation's result: <code
	xml:id="Output_FnAnns_1">bind_func(test,status(obsolete))</code></para>
	</section>

	<section>
	<title>Function's Specialization: 'cfa_function_specializations'</title>

	<synopsis>SYNTAX:
	cfa_function_specializations(//fn-name//, //guard//)</synopsis>

	<itemizedlist>
	<listitem>
	<para><emphasis>fn-name</emphasis> name of function</para>
	</listitem>

	<listitem>
	<para><emphasis>guard</emphasis> specialization guard</para>
	</listitem>
	</itemizedlist>

	<para>There is a possibility to have several functions with the same name
	called specializations. Each specialization is uniquely determined by
	annotation of special kind called <emphasis>guard</emphasis>.</para>

	<para>Example:</para>

	<programlisting xml:id="FnSpecs_1">name="tests/transcend-ast.cpp: ASTCorrespondence.Doc_BasicTests"
	guard:: arch(amd64)
	{
	test = function:: i64 {0}
	}</programlisting>

	<para>Translation's result: <code
	xml:id="Output_FnSpecs_1">cfa_function_specializations(test,arch(amd64))</code><note>
	<para>See also <link
	- xlink:href="/w/syntax#function-specializations">specializations
	+ xlink:href="/d/syntax/#function-specializations">specializations
	syntax</link></para>
	</note></para>
	</section>

	<section>
	<title>Function's Entry: 'cfa_parent'</title>

	<synopsis>SYNTAX:
	cfa_parent(//scope-entry-ref//, functon(//fn-name//))</synopsis>

	<itemizedlist>
	<listitem>
	<para><emphasis>scope-entry-ref</emphasis> function's entry code block
	reference</para>
	</listitem>

	<listitem>
	<para><emphasis>fn-name</emphasis> function's name</para>
	</listitem>
	</itemizedlist>

	<para>Each function has a single <emphasis>entry</emphasis> code block and
	is declared in terms of <emphasis>child-parent</emphasis> relation between
	entry block(which is top-level in blocks hierarchy of the given function)
	and the function itself.</para>

	<para>Example:</para>

	<programlisting xml:id="FnEntry_1">name="tests/transcend-ast.cpp: ASTCorrespondence.Doc_BasicTests"
	test = function:: int {0}</programlisting>

	<para>Translation's result: <code
	xml:id="Output_FnEntry_1">cfa_parent(0,function(test))</code></para>
	</section>

	<section>
	<title>Function's Result: 'dfa_fnret'</title>

	<synopsis>SYNTAX:
	dfa_fnret(//fn-name//, //symbol-ret-ref//)</synopsis>

	<itemizedlist>
	<listitem>
	<para>symbol-ret-ref reference to a function's return
	expression</para>
	</listitem>
	</itemizedlist>

	<para>Specifies which expression is used to compute function's return
	value.</para>

	<para>Example:</para>

	<programlisting xml:id="FnResult_1">name="tests/transcend-ast.cpp: ASTCorrespondence.Doc_BasicTests"
	test = function:: int {0}</programlisting>

	<para>Translation's result: <code
	xml:id="Output_FnResult_1">dfa_fnret(test,s(0,-2,0))</code></para>
	</section>

	<section>
	<title>Operations. Invocation: 'cfa_call', 'dfa_callfn',
	'dfa_callargs'</title>

	<synopsis>SYNTAX:
	cfa_call(//scope-caller-ref//, //fn-callee-name//) (1)
	dfa_callfn(//symbol-ref//, //fn-callee-name//) (2)
	dfa_callargs(//symbol-ref//, //arg-formal-name//, //arg-actual-ref//) (3)
	weak(dfa_callargs(//symbol-ref//, //arg-formal-name//, //arg-actual-ref//)) (4)
	</synopsis>

	<itemizedlist>
	<listitem>
	<para><emphasis>scope-caller-ref</emphasis> caller's code block's
	reference</para>
	</listitem>

	<listitem>
	<para><emphasis>fn-callee-name</emphasis> callee function name</para>
	</listitem>

	<listitem>
	<para><emphasis>symbol-ref</emphasis> invocation operation
	reference</para>
	</listitem>

	<listitem>
	<para><emphasis>arg-formal-name</emphasis> function's formal
	argument</para>
	</listitem>

	<listitem>
	<para><emphasis>arg-actual-ref</emphasis> actual argument
	reference</para>
	</listitem>
	</itemizedlist>

	<para>Each function invocation is transformed into several transcend facts
	as explained below:</para>

	<informaltable>
	<tgroup cols="2">
	<colspec colwidth="225*"/>

	<colspec colwidth="775*"/>

	<tbody>
	<row>
	<entry>(1) <code>cfa_call</code></entry>

	<entry>Specifies caller's code block and callee function
	name</entry>
	</row>

	<row>
	<entry>(2) <code>dfa_callfn</code></entry>

	<entry>Declares unique reference to a particular invocation
	site.The reference used by other facts to supply additional
	information</entry>
	</row>

	<row>
	<entry>(3) <code>dfa_callargs</code></entry>

	<entry>Declares assignment relations between actual arguments and
	formal arguments</entry>
	</row>

	<row>
	<entry>(4) <code>weak(dfa_callargs)</code></entry>

	<entry>The same as form (3). <emphasis>Weak</emphasis> relation
	used in cases when there is no enough information at compile time.
	One such case is when several function specializations exist and
	it's impossible to say which exactly specialization is
	called</entry>
	</row>
	</tbody>
	</tgroup>
	</informaltable>

	<para>Example:</para>

	<programlisting xml:id="OpInvoc_1">name="tests/transcend-ast.cpp: ASTCorrespondence.Doc_BasicTests"
	inc = function (x::int):: int
	{
	x + 1
	}

	main = function:: int
	{
	arg = 10:: int.
	inc(arg)
	}</programlisting>

	<para>After translation following transcend facts are present:</para>

	<programlisting xml:id="Output_OpInvoc_1">cfa_call(1,inc)
	dfa_callfn(s(0,-2,1),inc)
	weak(dfa_callargs(s(0,-2,1),s(1,-2,0),s(1,-2,1)))
	dfa_callargs(s(0,-2,1),s(1,-2,0),s(1,-2,1))</programlisting>
	</section>

	<section>
	<title>Operations. Loops</title>

	<synopsis>ast_op_map(//symbol-result-ref//, //symbol-source-ref//, //loop-body-ref//)
	ast_op_fold(//symbol-result-ref//, //symbol-source-ref//, //symbol-acc-ref//, //loop-body-ref//)</synopsis>

	<itemizedlist>
	<listitem>
	<para>symbol-source-ref input list reference</para>
	</listitem>

	<listitem>
	<para>symbol-acc-ref accumulator reference</para>
	</listitem>

	<listitem>
	<para>symbol-result-ref result list reference</para>
	</listitem>

	<listitem>
	<para>loop-body-ref refers to a loop body expression</para>
	</listitem>
	</itemizedlist>

	<para>Facts declare loop operations.</para>

	<para>Example:</para>

	<programlisting xml:id="OpLoops_1">name="tests/transcend-ast.cpp: ASTCorrespondence.Doc_BasicTests"
	test = function:: int; entry
	{
	singles = {1, 2, 3}:: [int].
	doubles = loop map(singles->element:: int)::[int] {2 * element}.
	doubles[0]
	}</programlisting>

	<para>produces fact: <code
	xml:id="Output_OpLoops_1">ast_op_map(s(2,-2,0),s(1,-2,0),s(0,-2,1))</code></para>
	</section>
	</chapter>
	diff --git a/documentation/Transcend/modules-api.xml b/documentation/Transcend/modules-api.xml
	index dc2d68e..215808b 100644
	--- a/documentation/Transcend/modules-api.xml
	+++ b/documentation/Transcend/modules-api.xml
	@@ -1,156 +1,156 @@
	<?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 2ahy8s1pw5c 7f?>

	<title><?xxe-sn 2ahy8s1pw5c 7g?>Modules API</title>

	<para><?xxe-sn 2ahy8s1pw5c 7h?>Modules Resolution is a process of finding
	out which modules should be preloaded for a correct compilation of a given
	module.</para>

	<para><?xxe-sn 2ahy8s1pw5c 7i?>Resolution expected to use <code><?xxe-sn 2ahy8s1pw5c 7j?>bind_module</code>,
	<code><?xxe-sn 2ahy8s1pw5c 7k?>modules_require</code> as an input and
	produce results in form of <code><?xxe-sn 2ahy8s1pw5c 7l?>modules_resolution</code>
	data table.</para>

	<section>
	<?xxe-sn 2ahy8s1pw5c 7m?>

	<title><?xxe-sn 2ahy8s1pw5c 7n?>Module Annotations: 'bind_module'</title>

	<synopsis><?xxe-sn 2ahy8s1pw5c 7o?>SYNTAX:
	bind_module(//module-ref//, //annotation//)</synopsis>

	<itemizedlist>
	<?xxe-sn 2ahy8s1pw5c 7p?>

	<listitem>
	<?xxe-sn 2ahy8s1pw5c 7q?>

	<para><?xxe-sn 2ahy8s1pw5c 7r?><emphasis><?xxe-sn 2ahy8s1pw5c 7s?>module-ref</emphasis>
	module's path</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 2ahy8s1pw5c 7t?>Declares module annotations.</para>

	<para><?xxe-sn 2ahy8s1pw5c 7u?>Example:</para>

	<programlisting xml:id="ModAnn_1"><?xxe-sn 2ahy8s1pw5c 7v?>name="tests/modules.cpp: Modules_API.Doc_ModAnn_1"
	module:: status(obsolete).</programlisting>

	<para><?xxe-sn 2ahy8s1pw5c 7w?>Produced fact: <code
	xml:id="Output_ModAnn_1"><?xxe-sn 2ahy8s1pw5c 7x?>bind_module("/path/to/module",status(obsolete))</code></para>
	</section>

	<section>
	<?xxe-sn 2ahy8s1pw5c 7y?>

	<title><?xxe-sn 2ahy8s1pw5c 7z?>Requesting Modules:
	'modules_require'</title>

	<synopsis><?xxe-sn 2ahy8s1pw5c 80?>SYNTAX:
	modules_require(//module-ref//, //request//)</synopsis>

	<itemizedlist>
	<?xxe-sn 2ahy8s1pw5c 81?>

	<listitem>
	<?xxe-sn 2ahy8s1pw5c 82?>

	<para><?xxe-sn 2ahy8s1pw5c 83?><emphasis><?xxe-sn 2ahy8s1pw5c 84?>module-ref</emphasis>
	module's path</para>
	</listitem>

	<listitem>
	<?xxe-sn 2ahy8s1pw5c 85?>

	<para><?xxe-sn 2ahy8s1pw5c 86?><emphasis><?xxe-sn 2ahy8s1pw5c 87?>request</emphasis>
	expressed by annotation</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 2ahy8s1pw5c 88?>Module can request other modules necessary
	for correct work. Declared requests can be processed to find a
	resolution.</para>

	<para><?xxe-sn 2ahy8s1pw5c 89?>Example:</para>

	<programlisting xml:id="ReqMod_1"><?xxe-sn 2ahy8s1pw5c 8a?>name="tests/modules.cpp: Modules_API.Doc_ReqMod_1"
	module
	{
	require(logger).
	}</programlisting>

	<para><?xxe-sn 2ahy8s1pw5c 8b?>Produced declaration: <code
	xml:id="Output_ReqMod_1"><?xxe-sn 2ahy8s1pw5c 8c?>modules_require("/path/to/module", logger)</code></para>
	</section>

	<section>
	<?xxe-sn 2ahy8s1pw5c 8d?>

	<title><?xxe-sn 2ahy8s1pw5c 8e?>Modules Resolution:
	'modules_resolution'</title>

	<synopsis><?xxe-sn 2ahy8s1pw5c 8f?>SYNTAX:
	modules_resolution(//request//, //module-resolved-ref//) (1)
	modules_resolution(//request//, //module-resolved-ref//, //module-context-ref//) (2)
	</synopsis>

	<itemizedlist>
	<?xxe-sn 2ahy8s1pw5c 8g?>

	<listitem>
	<?xxe-sn 2ahy8s1pw5c 8h?>

	<para><?xxe-sn 2ahy8s1pw5c 8i?><emphasis><?xxe-sn 2ahy8s1pw5c 8j?>request</emphasis>
	expressed by annotation</para>
	</listitem>

	<listitem>
	<?xxe-sn 2ahy8s1pw5c 8k?>

	<para><?xxe-sn 2ahy8s1pw5c 8l?><emphasis><?xxe-sn 2ahy8s1pw5c 8m?>module-resolved-ref</emphasis>
	resolved module's path</para>
	</listitem>

	<listitem>
	<?xxe-sn 2ahy8s1pw5c 8n?>

	<para><?xxe-sn 2ahy8s1pw5c 8o?><emphasis><?xxe-sn 2ahy8s1pw5c 8p?>module-context-ref</emphasis>
	context module's path</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 2ahy8s1pw5c 8q?>Xreate uses the data table to find
	correspondent modules for each request.</para>

	<para><?xxe-sn 2ahy8s1pw5c 8r?>Form (1) assigns resolved module to a
	request and assumes that assignment is valid in all cases, i.e. whenever
	compiler encounters request it loads associated module.</para>

	<para><?xxe-sn 2ahy8s1pw5c 8s?>Form (2) assigns resolution valid only in a
	specific context. Compiler uses particular resolution only for requests
	that came from a module specified in a context. In other words, form (2)
	allows to resolve the same request differently for different modules
	depending on resolution strategy, thus implementing <emphasis><?xxe-sn 2ahy8s1pw5c 8t?>polymorphism
	on module level</emphasis>.</para>
	</section>

	<section>
	<?xxe-sn 2ahy8s1pw5c 8u?>

	<title><?xxe-sn 2ahy8s1pw5c 8v?>See Also</title>

	<para><?xxe-sn 2ahy8s1pw5c 8w?>Syntax: <link
	- xlink:href="/w/syntax/modules"><?xxe-sn 2ahy8s1pw5c 8x?>Modules</link></para>
	+ xlink:href="/d/syntax/modules/"><?xxe-sn 2ahy8s1pw5c 8x?>Modules</link></para>
	</section>
	</chapter>
	diff --git a/documentation/Transcend/transcend.xml b/documentation/Transcend/transcend.xml
	index ad02e52..9ca00af 100644
	--- a/documentation/Transcend/transcend.xml
	+++ b/documentation/Transcend/transcend.xml
	@@ -1,443 +1,443 @@
	<?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 2ajela3ur5s 7q?>

	<title><?xxe-sn 2ajela3ur5s 7r?>Transcend</title>

	<para><?xxe-sn 2ajela3ur5s 7s?>Transcend is a compilation phase and process
	of reasoning about program in order to influence compilation.</para>

	<para><?xxe-sn 2ajela3ur5s 7t?>First, compiler extracts <emphasis><?xxe-sn 2ajela3ur5s 7u?>annotations</emphasis>
	from source code and other facts from number of sources to form a complete
	<emphasis><?xxe-sn 2ajela3ur5s 7v?>logic program</emphasis>. Then, solver
	processes logic program and outputs decisions that affect and control
	compilation process in a number of ways.</para>

	<section>
	<?xxe-sn 2ajela3ur5s 7w?>

	<title><?xxe-sn 2ajela3ur5s 7x?>Annotations' Syntax</title>

	<para><?xxe-sn 2ajela3ur5s 7y?>Xreate's annotations comprise optional
	supplementary information that is processed by compiler along with a
	source code proper and able to affect compilation process. Annotations
	have form of expressions that consist of following elements:</para>

	<informaltable>
	<?xxe-sn 2ajela3ur5s 7z?>

	<tgroup cols="2">
	<?xxe-sn 2ajela3ur5s 80?>

	<colspec colwidth="183*"><?xxe-sn 2ajela3ur5s 81?></colspec>

	<colspec colwidth="817*"><?xxe-sn 2ajela3ur5s 82?></colspec>

	<tbody>
	<?xxe-sn 2ajela3ur5s 83?>

	<row>
	<?xxe-sn 2ajela3ur5s 84?>

	<entry><?xxe-sn 2ajela3ur5s 85?>Literals</entry>

	<entry><?xxe-sn 2ajela3ur5s 86?>Strings, numbers. Example:
	<code><?xxe-sn 2ajela3ur5s 87?>5, "success"</code></entry>
	</row>

	<row>
	<?xxe-sn 2ajela3ur5s 88?>

	<entry><?xxe-sn 2ajela3ur5s 89?>Predicates</entry>

	<entry><?xxe-sn 2ajela3ur5s 8a?>Predicates have zero or more
	arguments. Example: <code><?xxe-sn 2ajela3ur5s 8b?>final, status(broken), version("12.0.3", unstable)</code></entry>
	</row>

	<row>
	<?xxe-sn 2ajela3ur5s 8c?>

	<entry><?xxe-sn 2ajela3ur5s 8d?>Negation</entry>

	<entry><?xxe-sn 2ajela3ur5s 8e?>Example: <code><?xxe-sn 2ajela3ur5s 8f?>-i12n, -access(allowed)</code></entry>
	</row>
	</tbody>
	</tgroup>
	</informaltable>

	<para><?xxe-sn 2ajela3ur5s 8g?>Various Xreate's entities can be annotated.
	At the time following entities are supported:</para>

	<informaltable>
	<?xxe-sn 2ajela3ur5s 8h?>

	<tgroup cols="4">
	<?xxe-sn 2ajela3ur5s 8i?>

	<tbody>
	<?xxe-sn 2ajela3ur5s 8j?>

	<row>
	<?xxe-sn 2ajela3ur5s 8k?>

	<entry><?xxe-sn 2ajela3ur5s 8l?><link
	xlink:href="#expression-and-identifiers"><?xxe-sn 2ajela3ur5s 8m?>Expressions
	and Identifiers</link></entry>

	<entry><?xxe-sn 2ajela3ur5s 8n?><link
	xlink:href="#code-blocks-and-context"><?xxe-sn 2ajela3ur5s 8o?>Code
	blocks and context</link></entry>

	<entry><?xxe-sn 2ajela3ur5s 8p?><link
	- xlink:href="/w/syntax#functions"><?xxe-sn 2ajela3ur5s 8q?>Functions</link>
	- and <link xlink:href="/w/syntax#function-guards"><?xxe-sn 2ajela3ur5s 8r?>Function
	+ xlink:href="/d/syntax/#functions"><?xxe-sn 2ajela3ur5s 8q?>Functions</link>
	+ and <link xlink:href="/d/syntax/#function-guards"><?xxe-sn 2ajela3ur5s 8r?>Function
	Guards</link></entry>

	<entry><?xxe-sn 2ajela3ur5s 8s?><link
	- xlink:href="/w/syntax/modules#module-annotations"><?xxe-sn 2ajela3ur5s 8t?>Modules</link></entry>
	+ xlink:href="/d/syntax/modules/#module-annotations"><?xxe-sn 2ajela3ur5s 8t?>Modules</link></entry>
	</row>
	</tbody>
	</tgroup>
	</informaltable>

	<section>
	<?xxe-sn 2ajela3ur5s 8u?>

	<title><?xxe-sn 2ajela3ur5s 8v?>Expression and Identifiers</title>

	<synopsis><?xxe-sn 2ajela3ur5s 8w?>SYNTAX:
	//expression// :: //type//; //annotation-list//.</synopsis>

	<itemizedlist>
	<?xxe-sn 2ajela3ur5s 8x?>

	<listitem>
	<?xxe-sn 2ajela3ur5s 8y?>

	<para><?xxe-sn 2ajela3ur5s 8z?><emphasis><?xxe-sn 2ajela3ur5s 90?>type</emphasis>
	expression's type</para>
	</listitem>

	<listitem>
	<?xxe-sn 2ajela3ur5s 91?>

	<para><?xxe-sn 2ajela3ur5s 92?><emphasis><?xxe-sn 2ajela3ur5s 93?>annotation-list</emphasis>
	one or more annotation attached to the expression. Annotations are
	delimited by semicolon</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 2ajela3ur5s 94?>Example:</para>

	<programlisting xml:id="Expressions1"><?xxe-sn 2ajela3ur5s 95?>name="tests/transcend.cpp: Transcend.Doc_Expressions1"
	test = function:: int
	{
	x = 5:: int; arithmetic(fast). //annotation applied to an identifier
	y = (x - 8:: int; arithm_optimization(off)) * 2:: float. //annotation applied to a nested expression

	x+y
	}</programlisting>

	<note>
	<?xxe-sn 2ajela3ur5s 96?>

	<para><?xxe-sn 2ajela3ur5s 97?>For readability sake compound
	- statements(e.g. <link xlink:href="/w/syntax#loop-statements"><?xxe-sn 2ajela3ur5s 98?>loops</link>)
	+ statements(e.g. <link xlink:href="/d/syntax/#loop-statements"><?xxe-sn 2ajela3ur5s 98?>loops</link>)
	have different syntax for an annotations. See particular statement's
	- <link xlink:href="/w/syntax"><?xxe-sn 2ajela3ur5s 99?>syntax</link>
	+ <link xlink:href="/d/syntax/"><?xxe-sn 2ajela3ur5s 99?>syntax</link>
	for details</para>
	</note>
	</section>

	<section>
	<?xxe-sn 2ajela3ur5s 9a?>

	<title><?xxe-sn 2ajela3ur5s 9b?>Code Blocks and Context</title>

	<synopsis><?xxe-sn 2ajela3ur5s 9c?>SYNTAX:
	context :: //annotations-list//.</synopsis>

	<itemizedlist>
	<?xxe-sn 2ajela3ur5s 9d?>

	<listitem>
	<?xxe-sn 2ajela3ur5s 9e?>

	<para><?xxe-sn 2ajela3ur5s 9f?><emphasis><?xxe-sn 2ajela3ur5s 9g?>annotations-list</emphasis>
	List of annotation delimited by semicolon</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 2ajela3ur5s 9h?>Code block annotations called
	<emphasis><?xxe-sn 2ajela3ur5s 9i?>context</emphasis>. Keyword
	<code><?xxe-sn 2ajela3ur5s 9j?>context</code> used to declare annotation
	within enclosing code block.</para>

	<para><?xxe-sn 2ajela3ur5s 9k?>Example:</para>

	<programlisting xml:id="Codeblocks1"><?xxe-sn 2ajela3ur5s 9l?>name="tests/transcend.cpp: Transcend.Doc_Codeblocks1"
	test = function:: int
	{
	context:: arithm_optimization(off).

	x = 10 :: int.
	2 * x - 16
	}</programlisting>
	</section>

	<section>
	<?xxe-sn 2ajela3ur5s 9m?>

	<title><?xxe-sn 2ajela3ur5s 9n?>Special Annotations</title>

	<para><?xxe-sn 2ajela3ur5s 9o?>There are some annotations in Xreate that
	have special meaning</para>

	<informaltable>
	<?xxe-sn 2ajela3ur5s 9p?>

	<tgroup cols="2">
	<?xxe-sn 2ajela3ur5s 9q?>

	<colspec colwidth="201*"><?xxe-sn 2ajela3ur5s 9r?></colspec>

	<colspec colwidth="799*"><?xxe-sn 2ajela3ur5s 9s?></colspec>

	<tbody>
	<?xxe-sn 2ajela3ur5s 9t?>

	<row>
	<?xxe-sn 2ajela3ur5s 9u?>

	<entry><?xxe-sn 2ajela3ur5s 9v?><code><?xxe-sn 2ajela3ur5s 9w?>entry</code></entry>

	<entry><?xxe-sn 2ajela3ur5s 9x?>Specifies entry point of a
	- program. See <link xlink:href="/w/syntax#functions"><?xxe-sn 2ajela3ur5s 9y?>Function
	+ program. See <link xlink:href="/d/syntax/#functions"><?xxe-sn 2ajela3ur5s 9y?>Function
	Syntax</link></entry>
	</row>

	<row>
	<?xxe-sn 2ajela3ur5s 9z?>

	<entry><?xxe-sn 2ajela3ur5s a0?><code><?xxe-sn 2ajela3ur5s a1?>final</code></entry>

	<entry><?xxe-sn 2ajela3ur5s a2?>Specifies fixed point of loop
	statements. See <link
	- xlink:href="/w/syntax#loop-statement"><?xxe-sn 2ajela3ur5s a3?>Loop
	+ xlink:href="/d/syntax/#loop-statement"><?xxe-sn 2ajela3ur5s a3?>Loop
	Statement</link></entry>
	</row>
	</tbody>
	</tgroup>
	</informaltable>
	</section>
	</section>

	<section>
	<?xxe-sn 2ajela3ur5s a4?>

	<title><?xxe-sn 2ajela3ur5s a5?>Annotations and Reasoning</title>

	<para><?xxe-sn 2ajela3ur5s a6?>Annotations is a mechanism to express an
	additional pieces of information and can occur in source code or
	accompanying files. They are of declarative nature in a sense that they
	express specific properties of and relations between different entities,
	such as: identifiers, statements, code blocks, functions, modules or even
	a whole program.</para>

	<para><?xxe-sn 2ajela3ur5s a7?>Annotations are <emphasis><?xxe-sn 2ajela3ur5s a8?>facts</emphasis>
	about source code provided by developer in explicit form. Beside
	annotations there are other sources of information, e.g. implicit facts
	that are automatically inferred by various analysis phases to express
	useful insights regarding analysed code. Such pieces aren't exposed
	directly to a developer but accessed and used internally at reasoning
	phase along with annotations. All types of input are summed up
	below:</para>

	<informaltable>
	<?xxe-sn 2ajela3ur5s a9?>

	<tgroup cols="2">
	<?xxe-sn 2ajela3ur5s aa?>

	<colspec colwidth="287*"><?xxe-sn 2ajela3ur5s ab?></colspec>

	<colspec colwidth="713*"><?xxe-sn 2ajela3ur5s ac?></colspec>

	<tbody>
	<?xxe-sn 2ajela3ur5s ad?>

	<row>
	<?xxe-sn 2ajela3ur5s ae?>

	<entry><?xxe-sn 2ajela3ur5s af?>Explicit annotations in source
	files</entry>

	<entry><?xxe-sn 2ajela3ur5s ag?>Annotations provided by developer
	in order to explicitly affect compilation</entry>
	</row>

	<row>
	<?xxe-sn 2ajela3ur5s ah?>

	<entry><?xxe-sn 2ajela3ur5s ai?>Code Analysis</entry>

	<entry><?xxe-sn 2ajela3ur5s aj?>Different code analyses during
	compilation provide information implicitly inferred from source
	code</entry>
	</row>

	<row>
	<?xxe-sn 2ajela3ur5s ak?>

	<entry><?xxe-sn 2ajela3ur5s al?>Supervision</entry>

	<entry><?xxe-sn 2ajela3ur5s am?>External facts that reflect
	requirements, describe hardware and/or environment where
	compilation takes place or program is supposed to work. There are
	many supervision layers possible, from custom compiler's mode, to
	OS- or computer- or even network-wide level. On other words,
	supervision covers local or client supplied annotations</entry>
	</row>

	<row>
	<?xxe-sn 2ajela3ur5s an?>

	<entry><?xxe-sn 2ajela3ur5s ao?>Audit</entry>

	<entry><?xxe-sn 2ajela3ur5s ap?>Third party supplied external
	information that reflect additional software properties, e.g.
	results of security audit</entry>
	</row>

	<row>
	<?xxe-sn 2ajela3ur5s aq?>

	<entry><?xxe-sn 2ajela3ur5s ar?>Reasoning rules</entry>

	<entry><?xxe-sn 2ajela3ur5s as?>Reasoning infers additional facts
	from pool of previously gathered information. It is done by using
	<emphasis><?xxe-sn 2ajela3ur5s at?>resoning rules</emphasis> that
	govern reasoning process</entry>
	</row>
	</tbody>
	</tgroup>
	</informaltable>
	</section>

	<section>
	<?xxe-sn 2ajela3ur5s au?>

	<title><?xxe-sn 2ajela3ur5s av?>Why Annotations Matter</title>

	<para><?xxe-sn 2ajela3ur5s aw?>This section goes through differences that
	annotations have over traditional statements.</para>

	<section>
	<?xxe-sn 2ajela3ur5s ax?>

	<title><?xxe-sn 2ajela3ur5s ay?>Extensible</title>

	<para><?xxe-sn 2ajela3ur5s az?>Annotations are not a part of language
	syntax and there is no predefined set of allowed annotations. Developer
	is free to define and use custom annotations to express desired
	properties without prior changes to compiler.</para>

	<note>
	<?xxe-sn 2ajela3ur5s b0?>

	<para><?xxe-sn 2ajela3ur5s b1?>Yet there are several reserved
	annotations that have specific meaning in Xreate. See <link
	xlink:href="#special-annotations"><?xxe-sn 2ajela3ur5s b2?>special
	annotations</link> for details.</para>
	</note>
	</section>

	<section>
	<?xxe-sn 2ajela3ur5s b3?>

	<title><?xxe-sn 2ajela3ur5s b4?>Indicative Nature</title>

	<para><?xxe-sn 2ajela3ur5s b5?>Unlike language statements that have well
	defined compilation output, annotation do not. They are rather of
	suggestive nature and actual impact depends on many factors. Annotations
	comprise an input for a reasoning procedure that ultimately determines
	how exactly influence compilation.</para>
	</section>

	<section>
	<?xxe-sn 2ajela3ur5s b6?>

	<title><?xxe-sn 2ajela3ur5s b7?>Cooperation</title>

	<para><?xxe-sn 2ajela3ur5s b8?>Annotations are gathered from different
	sources and this enables annotations to complement themselves. Compiler
	blends in annotations originated from various sources seamlessly and
	this allows to improve decisions quality.</para>
	</section>

	<section>
	<?xxe-sn 2ajela3ur5s b9?>

	<title><?xxe-sn 2ajela3ur5s ba?>External Sources and
	Adaptability</title>

	<para><?xxe-sn 2ajela3ur5s bb?>Annotations able to express not only
	properties of program itself but also properties of local
	environment(OS, computer, local network) where program is supposed to
	run. Thus compiler operates information inaccessible during software
	development and can't be reflected in the code otherwise. Compilation
	can be adjusted to a particular environment and functioning mode.</para>
	</section>

	<section>
	<?xxe-sn 2ajela3ur5s bc?>

	<title><?xxe-sn 2ajela3ur5s bd?>Feedback</title>

	<para><?xxe-sn 2ajela3ur5s be?>Traditionally software has a rigid
	strictly defined hierarchical structure and interaction between
	components. More precisely, let's look at client-service code model.
	Service is done independently in order to work well with as wide as
	possible set of different clients. Thus service is unaware of exact
	characteristics of particular client code it works with. All burden of
	complying with interaction specification lies on a client.</para>

	<para><?xxe-sn 2ajela3ur5s bf?>However client may use only small subset
	of service functionality or use it in specific and predictable order.
	Generally speaking, service by having additional information on
	particular client able to serve requests more efficiently in many
	cases.</para>

	<para><?xxe-sn 2ajela3ur5s bg?>It can be conceptualized as a
	<emphasis><?xxe-sn 2ajela3ur5s bh?>feedback</emphasis> from a client.
	Annotations is good candidate to express feedback to improve interaction
	quality.</para>
	</section>

	<section>
	<?xxe-sn 2ajela3ur5s bi?>

	<title><?xxe-sn 2ajela3ur5s bj?>Resiliency</title>

	<para><?xxe-sn 2ajela3ur5s bk?>As code grows and goes through multiple
	reworks and rewrites many initial assumptions about the code and
	relation between different parts change accordingly. Some implementation
	details and approaches became outdated and code quality
	deteriorates.</para>

	<para><?xxe-sn 2ajela3ur5s bl?>DIfferent picture in case if code uses
	annotations to express important properties. Any changes in underlying
	code lead to a restart of reasoning procedure which adjust
	implementation decisions to be still optimal in changed
	environment.</para>
	</section>
	</section>
	</chapter>
	diff --git a/documentation/build.xml b/documentation/build.xml
	new file mode 100644
	index 0000000..0b10cee
	--- /dev/null
	+++ b/documentation/build.xml
	@@ -0,0 +1,154 @@
	+<?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 2ckdfwgr1fk 1?>
	+
	+ <title><?xxe-sn 2ckdfwgr1fk 2?>Installation</title>
	+
	+ <section>
	+ <?xxe-sn 2ckdfwgr1fk 6?>
	+
	+ <title><?xxe-sn 2ckdfwgr1fk 7?>Build on Linux</title>
	+
	+ <para><?xxe-sn 2ckdfwgr1fk 8?>Major dependencies:</para>
	+
	+ <itemizedlist>
	+ <?xxe-sn 2ckdfwgr1fk 9?>
	+
	+ <listitem>
	+ <?xxe-sn 2ckdfwgr1fk a?>
	+
	+ <para><?xxe-sn 2ckdfwgr1fk b?>gcc 7</para>
	+ </listitem>
	+
	+ <listitem>
	+ <?xxe-sn 2ckdfwgr1fk c?>
	+
	+ <para><?xxe-sn 2ckdfwgr1fk d?>llvm 5, clang 5</para>
	+ </listitem>
	+
	+ <listitem>
	+ <?xxe-sn 2ckdfwgr1fk e?>
	+
	+ <para><?xxe-sn 2ckdfwgr1fk f?>boost 1.66</para>
	+ </listitem>
	+
	+ <listitem>
	+ <?xxe-sn 2ckdfwgr1fk g?>
	+
	+ <para><?xxe-sn 2ckdfwgr1fk h?>coco</para>
	+ </listitem>
	+
	+ <listitem>
	+ <?xxe-sn 2ckdfwgr1fk i?>
	+
	+ <para><?xxe-sn 2ckdfwgr1fk j?>clingo</para>
	+ </listitem>
	+ </itemizedlist>
	+
	+ <para><?xxe-sn 2ckdfwgr1fk k?>Building tested on <emphasis
	+ role="bold"><?xxe-sn 2ckdfwgr1fk l?>OpenSuse Leap 15</emphasis>. Please
	+ change commands accordingly if using other distributions.</para>
	+
	+ <para><?xxe-sn 2ckdfwgr1fk m?>Pull sources directly from
	+ repository:</para>
	+
	+ <literallayout><?xxe-sn 2ckdfwgr1fk n?>git clone --recursive https://pgess@bitbucket.org/pgess/xreate.git</literallayout>
	+
	+ <para><?xxe-sn 2ckdfwgr1fk o?>Enter into the source directory and run the
	+ following script to prepare building environment. Script will install the
	+ required system packages as well as Coco and Clingo from sources:</para>
	+
	+ <remark><?xxe-sn 2ckdfwgr1fk p?>"Enter into source directory" - тут перед
	+ directory явно нужен артикль. Гугл говорит, что определенный -
	+ the</remark>
	+
	+ <important>
	+ <?xxe-sn 2ckdfwgr1fk q?>
	+
	+ <para><?xxe-sn 2ckdfwgr1fk r?>Carefully inspect scripts before
	+ run</para>
	+ </important>
	+
	+ <para><?xxe-sn 2ckdfwgr1fk s?>On <emphasis role="bold"><?xxe-sn 2ckdfwgr1fk t?>OpenSuse
	+ Leap 15</emphasis>:</para>
	+
	+ <literallayout><?xxe-sn 2ckdfwgr1fk u?>./installation/prepare-opensuse-leap15</literallayout>
	+
	+ <para><?xxe-sn 2ckdfwgr1fk v?>That was one time operation to prepare
	+ environment. After that enter into <code><?xxe-sn 2ckdfwgr1fk w?>build</code>
	+ directory and start actual tests building:</para>
	+
	+ <remark><?xxe-sn 2ckdfwgr1fk x?>"build directory": здесь ты все-таки
	+ вначале указываешь имя объекта (build), и лишь потом родовое название
	+ (directory)</remark>
	+
	+ <literallayout><?xxe-sn 2ckdfwgr1fk y?>cd build
	+make</literallayout>
	+
	+ <para><?xxe-sn 2ckdfwgr1fk z?>After successful build you can run xreate
	+ tests:</para>
	+
	+ <literallayout><?xxe-sn 2ckdfwgr1fk 10?>cd ..
	+./build/tests/xreate-tests</literallayout>
	+
	+ <note>
	+ <?xxe-sn 2ckdfwgr1fk 11?>
	+
	+ <para><?xxe-sn 2ckdfwgr1fk 12?>Please pay attention that the working
	+ directory should be the repository root</para>
	+ </note>
	+
	+ <para><?xxe-sn 2ckdfwgr1fk 13?>For consequent rebuilds after updates etc
	+ invoke <code><?xxe-sn 2ckdfwgr1fk 14?>cmake</code> as follows:</para>
	+
	+ <literallayout><?xxe-sn 2ckdfwgr1fk 15?>#working dir build
	+cmake -DCMAKE_BUILD_TYPE=Debug \
	+ -DBUILD_XREATE_TESTS=1 \
	+ -DCOCO_EXECUTABLE=<FILE> \
	+ -DCLINGO_PATH=<DIR> \
	+ -DCOCO_FRAMES_PATH=../vendors/coco/generator/ \
	+ -DCMAKE_CXX_COMPILER=g++ ../cpp
	+make</literallayout>
	+
	+ <para><?xxe-sn 2ckdfwgr1fk 16?>Cmake's selected parameters:</para>
	+
	+ <itemizedlist>
	+ <?xxe-sn 2ckdfwgr1fk 17?>
	+
	+ <listitem>
	+ <?xxe-sn 2ckdfwgr1fk 18?>
	+
	+ <para><?xxe-sn 2ckdfwgr1fk 19?>BUILD_XREATE_TESTS Determines whether
	+ to build tests</para>
	+ </listitem>
	+
	+ <listitem>
	+ <?xxe-sn 2ckdfwgr1fk 1a?>
	+
	+ <para><?xxe-sn 2ckdfwgr1fk 1b?>COCO_EXECUTABLE Full filename of Coco
	+ executable</para>
	+ </listitem>
	+
	+ <listitem>
	+ <?xxe-sn 2ckdfwgr1fk 1c?>
	+
	+ <para><?xxe-sn 2ckdfwgr1fk 1d?>CLINGO_PATH Installed Clingo
	+ directory</para>
	+
	+ <remark><?xxe-sn 2ckdfwgr1fk 1e?>"Directory of Clingo installation":
	+ может, with Clingo installation? (это если речь идет о папке, где
	+ хранятся инсталляционные файлы) Если наоборот, куда будет
	+ устанавливаться - тогда Directory for installing Clingo. Оригинальный
	+ вариант ("of Clingo installation") немного сбивает с толку.</remark>
	+ </listitem>
	+ </itemizedlist>
	+ </section>
	+</chapter>
	diff --git a/documentation/exploitation.xml b/documentation/exploitation.xml
	index 39bd002..299281a 100644
	--- a/documentation/exploitation.xml
	+++ b/documentation/exploitation.xml
	@@ -1,490 +1,490 @@
	<?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 1?>

	<title><?xxe-sn 26yv439af40 2?>Exploitation</title>

	<para><?xxe-sn 26yv439af40 6?>This chapter discusses <emphasis><?xxe-sn 26yv439af40 7?>exploiting</emphasis>
	external resources, such as files, as a particular instance of a
	<emphasis><?xxe-sn 26yv439af40 8?>side effects</emphasis> problem that
	inevitably stems from an interaction with the outside world. Unlike <link
	- xlink:href="/w/virtualization"><?xxe-sn 295bzzou9kw 2?>virtualization</link>,
	+ xlink:href="/d/virtualization/"><?xxe-sn 295bzzou9kw 2?>virtualization</link>,
	an another documentation's topic that tackles I/O, exploitation approaches
	subject from a different angle — it is concerned with an <emphasis><?xxe-sn 26yv439af40 x?>order
	of operations</emphasis>, sequence in which different clients jointly use
	the same resource and it deals with corresponding difficulties, e.g. ensures
	proper resource initialization before actual usage.</para>

	<section>
	<?xxe-sn 29je46abuev -wunr7fl0rw8v?>

	<title><?xxe-sn 29je46abuev -wunr7fl0rw8u?>Syntax</title>

	<section>
	<?xxe-sn 29je46abuev -wunr7fl0rw8s?>

	<title><?xxe-sn 29je46abuev -wunr7fl0rw8r?>Annotations</title>

	<synopsis><?xxe-sn 29je46abuev -wunr7fl0rw8q?>SYNTAX:
	use(//resource-id//)
	init(//resource-id//)</synopsis>

	<itemizedlist>
	<?xxe-sn 29je46abuev -wunr7fl0rw8p?>

	<listitem>
	<?xxe-sn 29je46abuev -wunr7fl0rw8o?>

	<para><?xxe-sn 29je46abuev -wunr7fl0rw8n?><emphasis><?xxe-sn 29je46abuev -wunr7fl0rw8m?>resource-id</emphasis>
	— user-defined resource identifier</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 29je46abuev -wunr7fl0rw8l?>Annotates function or code
	block as such that exploits resource <emphasis><?xxe-sn 29je46abuev -wunr7fl0rw8k?>resource-id</emphasis>.</para>
	</section>

	<section>
	<?xxe-sn 29je46abuev -wunr7fl0rw8j?>

	<title><?xxe-sn 29je46abuev -wunr7fl0rw8i?>Guards</title>

	<synopsis><?xxe-sn 29je46abuev -wunr7fl0rw8h?>SYNTAX:
	exploitation(init)
	exploitation(none)</synopsis>

	<para><?xxe-sn 29je46abuev -wunr7fl0rw8g?>Specializations that are
	recognized by exploitation reasoning. Each specialization corresponds to
	an initialization strategy:</para>

	<itemizedlist>
	<?xxe-sn 29je46abuev -wunr7fl0rw8f?>

	<listitem>
	<?xxe-sn 29je46abuev -wunr7fl0rw8e?>

	<para><?xxe-sn 29je46abuev -wunr7fl0rw8d?><code><?xxe-sn 29je46abuev -wunr7fl0rw8a?>exploitation(init)</code>
	is expected to perform actual resource initialization.</para>
	</listitem>

	<listitem>
	<?xxe-sn 29je46abuev -wunr7fl0rw8c?>

	<para><?xxe-sn 29je46abuev -wunr7fl0rw8b?><code><?xxe-sn 29je46abuev -wunr7fl0rw89?>exploitation(none)</code>
	is expected to do nothing as initialization isn't necessary or done
	elsewhere.</para>
	</listitem>
	</itemizedlist>
	</section>
	</section>

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

	<title><?xxe-sn 26yv439af40 4?>Background</title>

	<para><?xxe-sn 26yv439af40 b?>In software engineering, the idea to avoid
	side effects have received considerable traction. Indeed, side effects is
	something that is hard to take into account and thus programs that have
	side effects are inherently unsafe, thus best coding practices are
	rightfully suggest to isolate side effects producing code as much as
	possible. It's so called pure functional languages whose philosophy goes
	even further and frames side effects as something opposite of "pure", and
	everything is built around effectless computations to the point that some
	languages' design itself includes side effects producing constructs, such
	as I/O, as an afterthought, as something almost unnecessary.</para>

	<para><?xxe-sn 26yv439af40 c?>However, in reality the opposite is true,
	most applications' sole responsibility is to communicate with "outside
	world", reacting to the external events and change "world state"
	accordingly. As a consequence, side effects usually are the
	<emphasis><?xxe-sn 26yv439af40 d?>only</emphasis> important effects the
	program produce and surely deserve first class support from a programming
	language and justify efforts to develop approach to alleviate related
	safety and performance concerns.</para>
	</section>

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

	<title><?xxe-sn 26yv439af40 10?>Exploitation Plan</title>

	<para><?xxe-sn 26yv439af40 12?>One complexity of taking side effects into
	account is the fact that final result depends on an <emphasis><?xxe-sn 28ivhnywem8 1?>exact
	operations order</emphasis>. This harshly impacts both performance and
	safety, for many techniques, e.g. caching, parallelization can neither be
	automatically performed nor validated since they are based on various
	degrees of reordering or deal with possibly undetermined beforehand order
	of execution.</para>

	<para><?xxe-sn 28ivhnywem8 2?>In this chapter, it is assumed, that final
	effects of execution fully defined by <emphasis><?xxe-sn 28ivhnywem8 3?>exploitation
	path</emphasis> — for a particular code path that can occur during
	execution, it is its part consisting of only relevant code blocks., i.e.
	those that deal with an exploited resource. Other code blocks do not
	influence exploitation effects and so are excluded from consideration.
	Thus reasoning about effects is reduced to considering all possible
	exploitation paths, checking do they meet certain requirements that define
	valid exploitation and making corrections if needed and possible.</para>

	<para><?xxe-sn 26yv439af40 13?>Result of the reasoning is called
	<emphasis><?xxe-sn 26yv439af40 14?>exploitation plan</emphasis> —
	specification that defines exact order and strategy of using a given
	resource in order to comply with imposed requirements.</para>

	<para><?xxe-sn 26yv439af40 15?>With all above said, the discussed approach
	can be presented as follows:</para>

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

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

	<para><?xxe-sn 26yv439af40 18?>Annotations are used to express some
	aspects of side effects to enable further reasoning. They indicate
	code blocks that deal with resource as well as provide additional
	information about how exactly it is exploited, e.g. use, initialize or
	deinitialize resource.</para>
	</listitem>

	<listitem>
	<?xxe-sn 28ivhnywem8 4?>

	<para><?xxe-sn 28ivhnywem8 5?>Existing code paths, extracted during
	source code processing, coupled with relevant annotations is enough to
	construct all possible exploitation paths and analyze them. Analysis
	determines possible(<emphasis><?xxe-sn 295bzzou9kw 3?>weak</emphasis>)
	paths that can occur or not during particular execution as well as
	certain paths(<emphasis><?xxe-sn 295bzzou9kw 4?>strong</emphasis>)
	that occur always no matter what. Also it checks are exploitation
	paths valid against certain rules, e.g. initialization occurs always
	before actual usage and is it possible to correct invalid
	paths.</para>
	</listitem>

	<listitem>
	<?xxe-sn 28ivhnywem8 6?>

	<para><?xxe-sn 28ivhnywem8 7?>Reasoning's result is an exploitation
	plan that dictates order and strategy of exploitation is presented in
	form of appropriate specialization for polymorphic functions that deal
	with resources in order to ensure safe exploitation to the extent
	based on provided annotations.</para>
	</listitem>

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

	<para><?xxe-sn 26yv439af40 1a?>Exploitation related side effects are
	viewed as a set of additional restrictions over operations order. Only
	subset of possible reorders is still valid w.r.t. side effects.
	Transcend's task is to find out refined set of valid orders. Thus
	techniques that rely on reordering enjoy additional information to
	make safe optimizations.</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 26yv439af40 1b?>... and it serves three major goals:</para>

	<itemizedlist>
	<?xxe-sn 26yv439af40 1c?>

	<listitem>
	<?xxe-sn 26yv439af40 1d?>

	<para><?xxe-sn 26yv439af40 1e?>Safety. Validates existing exploitation
	plan or is it possible to safely exploit given resource at all.
	Compiler signals error if a given exploitation plan is invalid, i.e.
	does not satisfy requirements w.r.t. side effects as expressed by
	annotations.</para>
	</listitem>

	<listitem>
	<?xxe-sn 28j5661y0mv -wunr7fl0rw8v?>

	<para><?xxe-sn 28j5661y0mv -wunr7fl0rw8u?>Regression Resilience. When
	it comes to using external resources, some spurious dependencies
	usually occur between otherwise isolated, independent components of a
	program. Sometimes refactoring and other code changes break those
	dependencies inevitably introducing regressions. Exploitation catches
	this sort of regressions and automatically regenerates exploitation
	plan suited for a changed conditions.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26yv439af40 1f?>

	<para><?xxe-sn 26yv439af40 1g?>Performance. Generated exploitation
	plans are optimal in a sense that they cut off superfluous operations,
	for example, removing resource initialization in several places if it
	can be done safely in a single one, thus reducing overall
	overhead.</para>
	</listitem>
	</itemizedlist>
	</section>

	<section>
	<?xxe-sn 27ay8x1a5mo 1?>

	<title><?xxe-sn 27ay8x1a5mo 2?>Domination Analysis</title>

	<para><?xxe-sn 27ay8x1a5mo 3?>When it comes to a reasoning about order of
	execution flow and possible code paths, crucial vehicle for that is
	<emphasis><?xxe-sn 27ay8x1a5mo 4?>domination analysis</emphasis> producing
	<emphasis><?xxe-sn 27ay8x1a5mo 5?>dominator tree</emphasis> as an
	output.</para>

	<para><?xxe-sn 27ay8x1a5mo 6?>Unlike the usual function-bounded domination
	analysis, when separate domination tree is produced for each function
	defined in a program, Exploitation requires program bound analysis, that
	is to take into account control flow across all functions in a program. It
	is computationally intensive task to perform analysis over a whole
	program, however it is compensated by the fact that Exploitation only
	takes into account code blocks that deal with, or in other words, exploit
	external resources. Thus there is no necessity to build full dominator
	tree, only the relevant parts are constructed, just enough to make sound
	exploitation plan decisions.</para>
	</section>

	<section>
	<?xxe-sn 28h47d43thc i?>

	<title><?xxe-sn 28h47d43thc j?>Empty Exploitation Plan. Effect Free
	Computations</title>

	<para><?xxe-sn 28h47d43thc k?>Validation of exploitation path is done
	against some predefined constraints. Depending on complexity of a
	constraints, i.e. number of different exploitation events that are seeking
	for in each path, reasoning goals categorized into several groups:</para>

	<itemizedlist>
	<?xxe-sn 28j5661y0mv -wunr7fl0rw8t?>

	<listitem>
	<?xxe-sn 28j5661y0mv -wunr7fl0rw8s?>

	<para><?xxe-sn 28j5661y0mv -wunr7fl0rw8r?>Zero Order Exploitation.
	Meaning that all paths are checked in terms is there exploitation at
	all or no, is there at least a single exploitation event along the
	path.</para>
	</listitem>

	<listitem>
	<?xxe-sn 28j5661y0mv -wunr7fl0rw8q?>

	<para><?xxe-sn 28j5661y0mv -wunr7fl0rw8p?>First Order Exploitation.
	Deals with a situations when it's enough to check only two different
	exploitation event occur in a required order. It can be useful for
	example, to check whether all resource uses occur after it is
	initialized.</para>
	</listitem>

	<listitem>
	<?xxe-sn 28j5661y0mv -wunr7fl0rw8o?>

	<para><?xxe-sn 28j5661y0mv -wunr7fl0rw8n?>Higher Order Exploitation.
	Expresses constraints involving several(more than two) exploitation
	events and relations between them.</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 28j5661y0mv -wunr7fl0rw8m?><emphasis><?xxe-sn 28j5661y0mv -wunr7fl0rw8l?>Empty
	Exploitation</emphasis> is an important instance of zero order constraint.
	It useful mechanism for developer to annotate function or part of a
	program as effect free in terms of exploitation. Thus, efectless, clean or
	pure code can be clearly separated from effectful part and compiler raises
	compilation error in case of accidental mixing or using "wrong" type of
	code in non appropriate environment.</para>
	</section>

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

	<title><?xxe-sn 26yv439af40 v?>Resource Initialization</title>

	<para><?xxe-sn 26yv439af40 w?>One important problem related to an
	exploitation order is to ensure that a given resource is properly
	initialized before its first usage and additionally it is not initialized
	more then once during exploitation session. This is instance of first
	order exploitation since in a validation mode it is enough to check
	exploitation plan to ensure that every resource usage preceded by resource
	initialization at some point in the <emphasis><?xxe-sn 28jw0wb6fpc 1?>past</emphasis>,
	i.e. previously in the exploitation path.</para>

	<para><?xxe-sn 28jw0wb6fpc 2?>For planning mode, the problem is addressed
	as follows:</para>

	<itemizedlist>
	<?xxe-sn 28jw0wb6fpc 3?>

	<listitem>
	<?xxe-sn 28jw0wb6fpc 4?>

	<para><?xxe-sn 28jw0wb6fpc 5?>Central idea of the algorithm is to
	consider candidates for initialization only among code blocks that
	<emphasis><?xxe-sn 295bzzou9kw 5?>dominate</emphasis> given usage
	site. Obviously, initialization in dominating block precedes usage for
	any possible code path.</para>
	</listitem>

	<listitem>
	<?xxe-sn 295bzzou9kw 6?>

	<para><?xxe-sn 295bzzou9kw 7?>One or more dominator blocks are chosen
	for actual initialization in such way that they are cover all found
	usage sites.</para>
	</listitem>

	<listitem>
	<?xxe-sn 295bzzou9kw 8?>

	<para><?xxe-sn 295bzzou9kw 9?>For code blocks chosen for
	initialization specialization <code><?xxe-sn 295bzzou9kw a?>exploitation(init)</code>
	is set, for the rest specialization <code><?xxe-sn 295bzzou9kw b?>exploitation(none)</code>
	is used.</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 28h47d43thc 1?>Look at the example below:</para>

	<programlisting xml:id="ResourceInit_1"><?xxe-sn 28h47d43thc 2?>name="tests/exploitation.cpp: Doc_ResourceInit_1", lines=15
	import raw("scripts/cfa/payload.lp").
	import raw("scripts/exploitation/exploitation.lp"). //exploitation reasoning
	import raw("scripts/exploitation/test1.assembly.lp").

	guard:: exploitation(init)
	{
	openFile = function(filePrev:: FILE_P):: FILE_P; init(file)
	{
	fopen("/tmp/test", "w")::FILE_P
	}
	}

	guard:: exploitation(none)
	{
	openFile = function(filePrev:: FILE_P):: FILE_P
	{
	filePrev::int
	}
	}

	test = function:: int; entry
	{
	seq
	{ f0 = undef:: FILE_P. f0 }
	{
	//Scope #1:
	f1 = openFile(f0):: FILE_P.
	f1
	}

	{ //Scope #2:
	f2 = openFile(f1):: FILE_P.
	f2
	}
	{
	//Scope #3:
	sizeWritten = fwrite("Attempt to write..", 12, 1, f2):: int; use(file).
	sizeWritten
	}
	{
	//Scope #4:
	fclose(f2):: int; use(file)
	}
	{ sizeWritten :: int}
	}</programlisting>

	<para><?xxe-sn 28h47d43thc 3?>There is the function <code><?xxe-sn 28h47d43thc 4?>test</code>
	that executes sequentially next commands: open a file(scopes #1, #2),
	write some text(scope #3) and finally, close the file(scope #4). It
	represents simple work flow with an external resource.</para>

	<para><?xxe-sn 28h47d43thc 7?>In order to connect the code to the
	exploitation the functions <code><?xxe-sn 28h47d43thc 5?>fwrite</code> and
	<code><?xxe-sn 28h47d43thc 6?>fclose</code> in scopes #3 and #4
	respectively are annotated with annotation <code><?xxe-sn 295bzzou9kw c?>use(file)</code>.
	This information is used by reasoning to look whether it is possible to
	initialize given resource before actual usage as well as where and when
	exactly to initialize it. Function <code><?xxe-sn 28h47d43thc 9?>openFile</code>
	is annotated as <code><?xxe-sn 28h47d43thc a?>init(file)</code> meaning it
	<emphasis><?xxe-sn 28h47d43thc b?>can</emphasis> initialize depending on
	chosen strategy. The function is invoked both in scope #1 and scope #2.
	Both scopes are executed <emphasis><?xxe-sn 28h47d43thc d?>strictly
	before</emphasis> scopes #3, #4. Thus it is indeed possible to initialize
	resource before usage. Next task for exploitation is to choose correct
	exploitation plan, i.e. to assign strategies for all possible
	initialization places in the effort to initialize resource only once.
	Here, it means that only one invocation of <code><?xxe-sn 28h47d43thc e?>openFile</code>
	is assigned with <code><?xxe-sn 28h47d43thc f?>exploitation(init)</code>
	to actually initialize the file. Other one is automatically marked with
	<code><?xxe-sn 28h47d43thc g?>exploitation(none)</code> to invoke
	different specialization of <code><?xxe-sn 28h47d43thc h?>openFile</code>
	that does nothing since the file is already initialized.</para>
	</section>
	</chapter>
	<?xxe-revisions
	#13 2019-03-07T18:19:21Z pgess
	#12 2019-02-09T15:16:04Z pgess
	1sPEAAABgYUGABiBhQgAAAoHc91tE6ZjQwVTMwDdbIN6om0=

	#11 2019-02-02T13:07:26Z pgess
	1sPEAAABgYUIAAyBhQgAAAQBc4GFCAA=
	#10 2019-02-01T17:38:23Z pgess
	1sPEAAABgYUKAIFE9icACGZQc28yPz5sZWFziRsTC0MIQ2oTC2OCNgECQ4MkU4s0IwcTC2PCVFMF
	MyRTFgEDM4kVEwVDCmMJU4I8EwxThHozgVuDDEOBGoMIMwljVVMMQwVTPBMEAQMTBxMGYw5TbUMP
	Yx9TLHMQEwcTChMJUxYAiR6YbxmDNI5ygjqDMb5tjjuLSbZOimemdYERpyObYagAiSKDYoJMhH3i
	gWejny2BIIFcqCZl6Q6TG4l51AGZa4N5lkeBJZzSBZdFigWdWA==
	#9 2019-01-26T14:30:18Z pgess
	1sPEAAAB9icAUfYlAAEqIGRz0wATB0OBHVMEQxszCBMFQzRTBTMEYwdjgRgTCAEBY4I9MwpDgVxj
	m00Ap2mrJoRxiR2ZGo5OijKLeq8mnUlJhCOBG54rgkGBYw==
	#8 2019-01-15T20:23:54Z pgess
	1sPEAAAB9ioAhCvvEAAlgiWBWTphc3NvY+KAlENzVW5ld2Jyb2tld2lmb3JzIDh0cmlnZ2MzZWRz
	hjUTDkNNEwgjBVMPAQFDQVNUAQVjBCMHMwQTBjMIY4wxUwdDgw5jfwEDUwQzihsBAVMiIwVjgRFD
	BFNTYwYzgnoTByMGAQFDix3UEwxDCjMGMwxjBVM2YxozBc0TBkMWEyBjbFMJUyVjDhMIMzdji11T
	CEMHMxVTBwEFYwSkY4I8kxZTK2OLHFMYM1EBAjOBEhMRUw0TEEOBPUMdMwSTCDMFUwlDBwEEYxET
	CUMMUyAzim8zEUMcYwVTIRMSQxozgV1TEZMLAQFjE2MKEwcBBTMEgwxjC1MGYwQzBjMOQ4EbM4FY
	UwkTBGMXAQFTD0MIUw5jTSMEEwtTBwEBUwczGpMIQwgzBVMGAQJjgQYTBTMFkwhjBmMHcwVTCYME
	UwQzCUODSwCGSj+FZK15XBNPiyyLPJR1hWWUNYNkpX6MOIMfiRmBCIolnGArgTQQdhKbF60ngxKE
	KINihiyoLp1okBUHN4hQjnyjB404oSOUH4lodqw8hHBFO4ZOqxeLbIIllBGGCCpGrHyDDC6HLFip
	eZ4Bg3iBQYFqhwi+jEQfpVuYPIl8mXqLN4dsin4bj20rhGeZD0++OQWCBYFdllSWf+JYhH8Oymig
	CB+BHoFDok6fa5MkgieFGRKBGqJyzHaLRL41cCiqf69yhAWEe4FAcM5PhGACnnsZgT6gNho=
	#7 2019-01-15T13:53:13Z pgess
	1sPEAAAB7xAAIuoxAAAQDHPREhMKQwRTQBMJExBjmDgAog2uVjCJF4N4hUU=
	#6 2019-01-15T11:27:29Z pgess
	1sPEAAAB6jIAF+dpAAAKB3PMJBMJQylTmxMAiReKLbtb
	#5 2019-01-15T08:04:19Z pgess
	1sPEAAAB520AglrYYQAogTF6RGF0aXNvZmluIGxpbVN0bDo6IEMxakRlLCwsaGxsIEluIHNoYWJ1
	dHOjSwEDEwYBAiMEAQJDCmMEYwtDTGMFUyIzBzMGEw9TgyxDDxMFYwYTCSMFIwoTBTMKEwkzJgEG
	MwQzC1OCV+ETBQEBQ1pjCVMMM0djBgEBY4EBAQFDJVMxEwZjdxMMQy4BA1MJYxJjFjMgYwQTGwEC
	YxkBAUMGAQFjBFMGAQODCZMMgywBATMIMwQBBkMEExL5EwdDC0MHYxJDBQECUwSDCVOGCQEDQ4Na
	gwkzKVObEwCRFaoCiCekAopDFIULT3MjmUcbgweMEYRHhjqtBLRjhWyRCoRwkXWCKoEaPYFqh32C
	W4EahyZxhydMgQJfnjBHgzSFHYs5rTyVBJE+oEODeJFFjn6SK50Al37CmTiVDYJ8kR9Wi06ZMoMu
	EoEUnUCXizOGEJeKLY5K
	#4 2019-01-14T13:48:02Z pgess
	1sPEAAAB2GUAgSjKVwAOVz0zPz5UdHRlc2hvdWxTcnOVKhMWQ4IsEwzdUwUBAWMEUwdjCGMJIwYB
	ATMFAQFjBFMIEx9TNVMEMwRjC1MMUxEBBRMEMwkzgl5TCmMLgyBDIwEBY4FMMw0zBFMXM4pXEwUB
	AWOgfQCVTSKDNKlVixtjgU2UA4k+mUicDoljFoQumTyORYVtRoN7HZdigjEdkjOBQiyJVjmVRIRC
	gQeCUZlRh2Q=
	#3 2018-12-24T11:55:39Z pgess
	1sPEAAAByiAAglmxQABBgSBxZmxmbWZucmVzdWxpbmRpdmlkZG8gc28sIGJvZ3VzIGdsb2JpcyBs
	bCBsQ0ZHNz8+QS04Pz5mb3J3bzk/PnAvPgpzpUkTCwECQx8BAlMZUyUBAmMpM4EjU4IUYwgBBRMF
	Mw4TBhMJQwcBB2MMMwQTC0MgMwYzByMPQyVDCwERYwRDBRMFYwUzBEMJUwQTBAEDEwQzB+LWUw4B
	A0MKExBzCwEEUwUzBiMMAQEzCFMKYwQTF3MLAQczBFMHAQFDDTMGExRzCwEEQwSDByMPUwRDBRMF
	Qw1TKWOCS3MLAQETCAECAIM0DKp5LlmhW4E7gxWgXIJenROObIhji1uHGoNjOIxDiwt0S5NdhiSN
	F4xGlnaRBothlSWICkSYHIYbimyXV4I3g3jJhQKEEIIQi1uDJJ8LhCvJjEOBfINCl0GELsmHL8VC
	hTySPYYHhl2NPYcQxAE=
	#2 2018-12-24T11:20:18Z pgess
	1sPEAAABsUAAErE4AAAHBXOwUxMGQ18AqheGSg==
	#1 2018-12-18T16:02:30Z pgess
	1sPEAAABsT0AMqdsAAIYEm9sc6JqAQITDEMLQwuDIDODMhMLQ2JDFGMLAJhklUuCMJSIGoM0izSB
	dIJQ
	-?>
	\ No newline at end of file
	+?>
	diff --git a/documentation/index.xml b/documentation/index.xml
	index d359a74..5033a93 100644
	--- a/documentation/index.xml
	+++ b/documentation/index.xml
	@@ -1,356 +1,216 @@
	<?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" has very specific meaning,
	implying 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 the three dimensions:
	efficiency, safety, and adaptability. 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. Xreate's design
	principles allow to adopt any programming technique as long as it does not
	improve one dimension at the expense of another.</para>

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

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

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

	- <para><?xxe-sn 2b06cb2u4g0 g?><link xlink:href="/w/syntax"><?xxe-sn 2b06cb2u4g0 o?>Brute</link>.
	+ <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="/w/transcend"><?xxe-sn 2b06cb2u4g0 q?>Transcend</link>.
	+ <para><?xxe-sn 2b06cb2u4g0 j?><link xlink:href="/d/transcend/"><?xxe-sn 2b06cb2u4g0 q?>Transcend</link>.
	Brute level 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 layer called
	<emphasis><?xxe-sn 2b06cb2u4g0 s?>Transcend</emphasis>. Transcend due to
	its declarative nature is appropriate to do management-type work — it
	analyzes, oversees and controls brute by guiding compilation process.
	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.</para>
	</listitem>

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

	<para><?xxe-sn 2b06cb2u4g0 m?><link
	- xlink:href="/w/concepts/interpretation/"><?xxe-sn 2b06cb2u4g0 r?>Interpretation</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 and
	their respective low level and high level constructs and
	structures.</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="/w/transcend"><?xxe-sn 2b06cb2u4g0 w?>annotations</link></emphasis>
	+ xlink:href="/d/transcend/"><?xxe-sn 2b06cb2u4g0 w?>annotations</link></emphasis>
	— arbitrary unconstrained metadata that 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 xlink:href="w/virtualization/"><?xxe-sn 2b3f3osfk74 g?>Most severe and
	hard to resolve problems in software development stem from interaction of
	different components on different levels. Each individual component often is
	thoroughly tested and works reliably. But combining them when building
	end-user software for which purpose complex interaction and extensive IO is
	enabled usually leads to a range of runtime errors, security vulnerabilities
	and performance degradation.</para>

	<para xlink:href="w/virtualization/"><?xxe-sn 2cdtco54w00 2?>Thus Xreate
	places key emphasis on domain-specific component level improvements and
	joint use of external resources. This aspect is covered in <link
	- xlink:href="/w/exploitation/"><?xxe-sn 2b3f3osfk74 h?>exploitation</link>
	- and <link xlink:href="/w/concepts/containers/"><?xxe-sn 2b3f3osfk74 i?>containers</link>
	+ xlink:href="/d/exploitation/"><?xxe-sn 2b3f3osfk74 h?>exploitation</link>
	+ and <link xlink:href="/d/concepts/containers/"><?xxe-sn 2b3f3osfk74 i?>containers</link>
	chapters.</para>

	<para xlink:href="w/virtualization/"><?xxe-sn 2cdtco54w00 3?>Unlike academic
	languages, Xreate targets safe and reliable usage of effectful computations
	- such as IO covered in <link xlink:href="/w/virtualization"><?xxe-sn 2b3f3osfk74 j?>virtualization</link>
	- and <link xlink:href="/w/exploitation/"><?xxe-sn 2b3f3osfk74 k?>exploitation</link>
	+ such as IO covered in <link xlink:href="/d/virtualization/"><?xxe-sn 2b3f3osfk74 j?>virtualization</link>
	+ and <link xlink:href="/d/exploitation/"><?xxe-sn 2b3f3osfk74 k?>exploitation</link>
	chapters, and mutable structures covered in <link
	- xlink:href="/w/communication/"><?xxe-sn 2b3f3osfk74 l?>communication</link>.</para>
	+ xlink:href="/d/communication/"><?xxe-sn 2b3f3osfk74 l?>communication</link>.</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
	{
	a / b
	}
	}

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

	test = function:: float; 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
	compiler because of annotation <code><?xxe-sn 2b06cb2u4g0 10?>entry</code>
	in its signature. There are also two functions <code><?xxe-sn 2b06cb2u4g0 11?>div</code>
	called <emphasis><?xxe-sn 2b06cb2u4g0 12?>specializations</emphasis>. Each
	specialization has a guard that defines a condition 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 developer specifies 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, although it is
	unacceptably slow due to an extra check instruction. This is a basis of
	- <link xlink:href="/w/concepts/polymorphism/"><?xxe-sn 2b3f3osfk74 2?>polymorphism</link>
	+ <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>
	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 2ba2e84701s 1?>
	-
	- <title><?xxe-sn 2ba2e84701s 2?>Build and Run on Linux</title>
	-
	- <para><?xxe-sn 2ba2e84701s 3?>Major dependencies:</para>
	-
	- <itemizedlist>
	- <?xxe-sn 2ba2e84701s 4?>
	-
	- <listitem>
	- <?xxe-sn 2ba2e84701s 5?>
	-
	- <para><?xxe-sn 2ba2e84701s 6?>gcc 7</para>
	- </listitem>
	-
	- <listitem>
	- <?xxe-sn 2ba2e84701s 7?>
	-
	- <para><?xxe-sn 2ba2e84701s 8?>llvm 5, clang 5</para>
	- </listitem>
	-
	- <listitem>
	- <?xxe-sn 2ba2e84701s 9?>
	-
	- <para><?xxe-sn 2ba2e84701s a?>boost 1.66</para>
	- </listitem>
	-
	- <listitem>
	- <?xxe-sn 2ba2e84701s b?>
	-
	- <para><?xxe-sn 2ba2e84701s c?>coco</para>
	- </listitem>
	-
	- <listitem>
	- <?xxe-sn 2ba2e84701s d?>
	-
	- <para><?xxe-sn 2ba2e84701s e?>clingo</para>
	- </listitem>
	- </itemizedlist>
	-
	- <para><?xxe-sn 2ba2e84701s f?>Building tested on <emphasis
	- role="bold"><?xxe-sn 2ba2e84701s o?>OpenSuse Leap 15</emphasis>. Please
	- change commands accordingly if using other distributions.</para>
	-
	- <para><?xxe-sn 2ba2e84701s p?>Pull sources directly from
	- repository:</para>
	-
	- <literallayout><?xxe-sn 2ba2e84701s g?>git clone --recursive https://pgess@bitbucket.org/pgess/xreate.git</literallayout>
	-
	- <para><?xxe-sn 2ba2e84701s q?>Enter into the source directory and run the
	- following script to prepare building environment. Script will install the
	- required system packages as well as Coco and Clingo from sources:</para>
	-
	- <remark><?xxe-sn 2ccp2iy80zj 1td6aqezxvj7p?>"Enter into source directory"
	- - тут перед directory явно нужен артикль. Гугл говорит, что определенный -
	- the</remark>
	-
	- <important>
	- <?xxe-sn 2cdtco54w00 4?>
	-
	- <para><?xxe-sn 2cdtco54w00 5?>Carefully inspect scripts before
	- run</para>
	- </important>
	-
	- <para><?xxe-sn 2ba2e84701s 13?>On <emphasis role="bold"><?xxe-sn 2ba2e84701s 14?>OpenSuse
	- Leap 15</emphasis>:</para>
	-
	- <literallayout><?xxe-sn 2ba2e84701s t?>./installation/prepare-opensuse-leap15</literallayout>
	-
	- <para><?xxe-sn 2ba2e84701s u?>That was one time operation to prepare
	- environment. After that enter into <code><?xxe-sn 2ba2e84701s v?>build</code>
	- directory and start actual tests building:</para>
	-
	- <remark><?xxe-sn 2ccp2iy80zj 1td6aqezxvj7q?>"build directory": здесь ты
	- все-таки вначале указываешь имя объекта (build), и лишь потом родовое
	- название (directory)</remark>
	-
	- <literallayout><?xxe-sn 2ba2e84701s w?>cd build
	-make</literallayout>
	-
	- <para><?xxe-sn 2ba2e84701s x?>After successful build you can run xreate
	- tests:</para>
	-
	- <literallayout><?xxe-sn 2ba2e84701s y?>cd ..
	-./build/tests/xreate-tests</literallayout>
	-
	- <note>
	- <?xxe-sn 2ba2e84701s 1h?>
	-
	- <para><?xxe-sn 2ba2e84701s 1i?>Please pay attention that the working
	- directory should be the repository root</para>
	- </note>
	-
	- <para><?xxe-sn 2ba2e84701s 17?>For consequent rebuilds after updates etc
	- invoke <code><?xxe-sn 2ba2e84701s 18?>cmake</code> as follows:</para>
	-
	- <literallayout><?xxe-sn 2ba2e84701s 19?>#working dir build
	-cmake -DCMAKE_BUILD_TYPE=Debug \
	- -DBUILD_XREATE_TESTS=1 \
	- -DCOCO_EXECUTABLE=<FILE> \
	- -DCLINGO_PATH=<DIR> \
	- -DCOCO_FRAMES_PATH=../vendors/coco/generator/ \
	- -DCMAKE_CXX_COMPILER=g++ ../cpp
	-make</literallayout>
	-
	- <para><?xxe-sn 2ba2e84701s 1j?>Cmake's selected parameters:</para>
	-
	- <itemizedlist>
	- <?xxe-sn 2ba2e84701s 1a?>
	-
	- <listitem>
	- <?xxe-sn 2ba2e84701s 1b?>
	-
	- <para><?xxe-sn 2ba2e84701s 1c?>BUILD_XREATE_TESTS Determines whether
	- to build tests</para>
	- </listitem>
	-
	- <listitem>
	- <?xxe-sn 2ba2e84701s 1d?>
	-
	- <para><?xxe-sn 2ba2e84701s 1e?>COCO_EXECUTABLE Full filename of Coco
	- executable</para>
	- </listitem>
	-
	- <listitem>
	- <?xxe-sn 2ba2e84701s 1f?>
	-
	- <para><?xxe-sn 2ba2e84701s 1g?>CLINGO_PATH Installed Clingo
	- directory</para>
	-
	- <remark><?xxe-sn 2ccp2iy80zj 1td6aqezxvj7r?>"Directory of Clingo
	- installation": может, with Clingo installation? (это если речь идет о
	- папке, где хранятся инсталляционные файлы) Если наоборот, куда будет
	- устанавливаться - тогда Directory for installing Clingo. Оригинальный
	- вариант ("of Clingo installation") немного сбивает с толку.</remark>
	- </listitem>
	- </itemizedlist>
	- </section>
	</chapter>
	diff --git a/documentation/manual.json b/documentation/manual.json
	index f2ed4b0..8c9f315 100644
	--- a/documentation/manual.json
	+++ b/documentation/manual.json
	@@ -1,35 +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": "Transcend", "pages": [
	- {"title": "Overview", "slug": "transcend/", "filename": "transcend.xml.remarkup", "subtitle": "Logic, declarative level of Xreate"},
	- {"title": "Late Transcend", "slug": "transcend/late-transcend/", "filename": "latetranscend.xml.remarkup", "subtitle": "How reasoning is able to work at runtime"}
	+ {"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": "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": "Interpretation", "slug": "concepts/interpretation/", "filename": "interpretation.xml.remarkup", "subtitle": "Explains compile time computations and more"}
	+ {"title": "Interpretation", "slug": "concepts/interpretation/", "filename": "interpretation.xml.remarkup", "subtitle": "Compile time computations and more"}
	]},

	- {"title": "Libraries", "pages": [
	+ {"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": "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": ""}
	]}
	]
	}
	diff --git a/documentation/virtualization.xml b/documentation/virtualization.xml
	index fea27c3..cafe5f1 100644
	--- a/documentation/virtualization.xml
	+++ b/documentation/virtualization.xml
	@@ -1,541 +1,541 @@
	<?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 1k?>

	<title><?xxe-sn 26yv439af40 1l?>Virtualization</title>

	<para><?xxe-sn 26yv439af40 1m?>The chapter expands on the usage of context
	based polymorphism, in other words, reasoning over CFG, as a ground to
	implement <emphasis><?xxe-sn 26yv439af40 1n?>application level
	virtualization</emphasis>.</para>

	<remark><?xxe-sn 2c3rmc3fvnj 1td6aqezxvj7l?>Желательно расшифровать
	аббревиатуру CFG, до этого она нигде не встречалась, и мне не ясно что она
	означает</remark>

	<para><?xxe-sn 26yv439af40 1o?>One way to approach the virtualization
	problem is to model it in terms of satisfying constraints imposed by
	environment over agents that operate within it, as presented below:</para>

	<itemizedlist>
	<?xxe-sn 26yv439af40 1p?>

	<listitem>
	<?xxe-sn 26yv439af40 1q?>

	<para><?xxe-sn 26yv439af40 1r?><emphasis><?xxe-sn 26yv439af40 1s?>sizo</emphasis>
	(distorted abbreviation for SEcurity ZOne): logical entity introduced to
	represent an environment and describe the desired virtualization
	outcome.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26yv439af40 1t?>

	<para><?xxe-sn 26yv439af40 1u?><emphasis><?xxe-sn 26yv439af40 1v?>zek</emphasis>
	(distorted abbreviation for SEcurity aGent): represents behaviour of the
	code in terms of virtualized resources access.</para>

	<remark><?xxe-sn 2c3rmc3fvnj 1td6aqezxvj7m?>По поводу длинных тире:
	насколько я знаю, они практически не используются в английском языке
	(как и наши «типографские» кавычки). Только короткие. Но эту информацию
	нужно проверить (PS: сегодня читал книгу на английском, и таки увидел
	там длинные тире).</remark>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 26yv439af40 1w?>Basic idea is to automatically reason over
	information defined by sizos and zeks and produce <emphasis><?xxe-sn 26yv439af40 1x?>virtualization
	plan</emphasis> as a solution that dictates which parts of code should be
	virtualized and how exactly. Such reasoning enables two features:</para>

	<itemizedlist>
	<?xxe-sn 26yv439af40 1y?>

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

	<para><?xxe-sn 26yv439af40 20?>Optimization. Allows choosing
	virtualization technique with the smallest performance penalty
	nevertheless satisfying necessary requirements.</para>
	</listitem>

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

	<para><?xxe-sn 26yv439af40 22?>Safety. Validates manually chosen
	virtualization plan to ensure it is solid and operable by checking that
	it indeed satisfies requirements.</para>

	<remark><?xxe-sn 2c3rmc3fvnj 1td6aqezxvj7n?>Я бы вообще сократил: "to
	ensure it is solid, operable and satisfying the necessary
	requirements"</remark>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 26yv439af40 23?>In other words, context based reasoning
	provides improvements by virtualizing only necessary sections of code and
	only for necessary type of resources by employing as lightweight
	virtualization strategy as possible – just enough to comply with the safety
	and security requirements expressed by annotations in the code.</para>

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

	<title><?xxe-sn 26yv439af40 25?>Background</title>

	<para><?xxe-sn 26yv439af40 26?><emphasis><?xxe-sn 26yv439af40 27?>Virtualization</emphasis>
	refers to abstracting code from the underlying <emphasis><?xxe-sn 26yv439af40 28?>resources</emphasis>
	used by it. Here the term 'resource' depicts any external entity such as a
	device, file, network connection etc, for which it is desirable to
	regulate access.</para>

	<para><?xxe-sn 26yv439af40 29?>Virtualization is a vast area and broad
	term that includes number of techniques on different levels to achieve
	several important goals such as:</para>

	<itemizedlist>
	<?xxe-sn 26yv439af40 2a?>

	<listitem>
	<?xxe-sn 26yv439af40 2b?>

	<para><?xxe-sn 26yv439af40 2c?>Shared access — allowing several
	clients to use the same resource while behaving as if each client were
	sole resource user, to simplify development and testing.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26yv439af40 2d?>

	<para><?xxe-sn 26yv439af40 2e?>Isolation — cornerstone of safety and
	behaviour repeatability achieved by minimizing influence of isolated
	clients between each other and external environment.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26yv439af40 2f?>

	<para><?xxe-sn 26yv439af40 2g?>Adaptation — allowing client
	application work in an unexpected environment it was not developed
	for, by emulating "native" familiar environment thus reducing
	adaptation and support costs.</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 26yv439af40 2h?>Due to the importance of goals achievable
	with virtualization, it is unavoidable in a long run. That being said,
	basic virtualization techniques have performance penalties arising from
	indirect and regulated access to underlying resources.</para>

	<para><?xxe-sn 26yv439af40 2i?>Further discussion is concerned with what
	can be done to alleviate major virtualization inefficiencies by
	fine-grained control over what should be virtualized, when, and
	how.</para>
	</section>

	<section>
	<?xxe-sn 26yv439af40 2j?>

	<title><?xxe-sn 26yv439af40 2k?>Access Control</title>

	<para><?xxe-sn 26yv439af40 2l?>A whole program can be broken down into one
	or more virtualization zones, each having different appropriate type of
	virtualization strategy. Such approach allows to model <emphasis><?xxe-sn 26yv439af40 2m?>hybrid
	virtualization</emphasis>, i.e. different parts of a program are
	virtualized differently depending on certain conditions. To capture this
	concept, the term <emphasis><?xxe-sn 26yv439af40 2n?>sizo</emphasis> is
	introduced, that refers to a logical entity that holds information about a
	particular zone necessary to find best suited virtualization
	strategy.</para>

	<important>
	<?xxe-sn 26yv439af40 2o?>

	<para><?xxe-sn 26yv439af40 2p?>Sizo is associated with <link
	- xlink:href="/w/concepts/context"><?xxe-sn 26yv439af40 2q?>context</link>,
	+ xlink:href="/d/concepts/context/"><?xxe-sn 26yv439af40 2q?>context</link>,
	i.e. each zone spans over one or more code blocks.</para>
	</important>

	<para><?xxe-sn 26yv439af40 2r?>There is an annotation <code><?xxe-sn 26yv439af40 2s?>assign_sizo</code>
	to specify sizo a code block is assigned to:</para>

	<synopsis><?xxe-sn 26yv439af40 2t?>SYNTAX:
	assign_sizo(//sizo-ref//).</synopsis>

	<itemizedlist>
	<?xxe-sn 26yv439af40 2u?>

	<listitem>
	<?xxe-sn 26yv439af40 2v?>

	<para><?xxe-sn 26yv439af40 2w?><emphasis><?xxe-sn 26yv439af40 2x?>sizo-ref</emphasis>
	unique sizo's identifier</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 26yv439af40 2y?>Next thing is to specify which resources a
	particular sizo controls access to, as demonstrated below:</para>

	<synopsis><?xxe-sn 26yv439af40 2z?>SYNTAX:
	assign_sizo_control(//resource-type//).</synopsis>

	<para><?xxe-sn 26yv439af40 30?>It indicates that the current sizo (sizo
	that spans over the code block wherein the annotation is located)
	regulates all access to resources of a given type, <emphasis><?xxe-sn 26yv439af40 31?>resource-type</emphasis>.
	Conversely, if for a particular environment there is no need to control
	e.g. file system access, no virtualization for file operations is
	applied.</para>

	<para><?xxe-sn 26yv439af40 32?>On the other hand, there is an annotation
	to mark a function that accesses one or another resource:</para>

	<synopsis><?xxe-sn 26yv439af40 33?>SYNTAX:
	assign_zek_access(//resource-type//).</synopsis>

	<para><?xxe-sn 26yv439af40 34?>Let's consider an example to demonstrate
	all the above:</para>

	<programlisting xml:id="AccControl_1"><?xxe-sn 26yv439af40 35?>name="tests/virtualization.cpp: Virtualization.Doc_AccControl_1", lines=15
	import raw ("scripts/cfa/context.lp"). //enable context reasoning
	import raw ("scripts/virtualization/virtualization.lp"). //enable virtualization reasoning

	guard:: strategy(direct)
	{
	openFile = function(filename::string):: int
	{
	printf("direct file access")
	}
	}

	guard:: strategy(common)
	{
	openFile = function(filename::string):: int;
	assign_zek_access(files)
	{
	printf("virtualized file access")
	}
	}

	main = function:: int; entry
	{
	context:: assign_sizo(zoneA);
	assign_sizo_control(files).
	openFile("/some/file")
	}</programlisting>

	<para><?xxe-sn 26yv439af40 36?>The example outlines a dummy function
	<code><?xxe-sn 26yv439af40 37?>openFile</code> to model file system
	access. The function includes two specializations with the <code><?xxe-sn 26yv439af40 38?>strategy(direct)</code>
	guard to model direct access, and the <code><?xxe-sn 26yv439af40 39?>strategy(common)</code>guard
	to be invoked if virtualization is enabled. It is also annotated with
	<code><?xxe-sn 26yv439af40 3a?>assign_zek_access(files)</code> to indicate
	that it accesses the file system. On the other hand, the context of the
	function <code><?xxe-sn 26yv439af40 3b?>main</code> defines the
	<code><?xxe-sn 26yv439af40 3c?>zoneA</code> sizo and enables control over
	file operations.</para>

	<para><?xxe-sn 26yv439af40 3d?>Reasoning works with the provided
	information and decides whether it is necessary to enable virtualization.
	In this case, the answer is yes for <code><?xxe-sn 26yv439af40 3e?>zoneA</code>,
	because of the fact that the sizo controls file operations and that there
	is actually a function within the sizo that requires file access.
	Consequently, the example outputs the following:<screen
	xml:id="Output_AccControl_1"><?xxe-sn 26yv439af40 3f?>virtualized file access</screen>confirming
	that specifically virtualized specialization of <code><?xxe-sn 26yv439af40 3g?>openFile</code>
	was invoked.</para>
	</section>

	<section>
	<?xxe-sn 26yv439af40 3h?>

	<title><?xxe-sn 26yv439af40 3i?>Isolation</title>

	<para><?xxe-sn 26yv439af40 3j?>As shown in the previous section, it is
	possible to enable (or disable) virtualization on a per resource basis.
	However, such functionality is limited in a sense that if several sizos
	allow access to the same resource they can interfere with each other.
	Thus, next step to consider is <emphasis><?xxe-sn 26yv439af40 3k?>isolation</emphasis>,
	i.e. zeks in different sizos should not have the ability to access the
	same resource, but rather work with their own set of resources associated
	with a particular sizo. The following examples, just as the previous one,
	are focused on file operations as the most ubiquitous type of
	resources.</para>

	<para><?xxe-sn 26yv439af40 3l?>One way to isolate file access is to
	associate a unique file prefix with each sizo. If virtualization is
	enabled, all filenames in the sizo are silently transformed on the fly by
	adding an assigned prefix. This way, all the file operations from one sizo
	are confined within a specific directory allocated solely for that
	particular sizo, or simply have a unique prefix if the same directory
	contains files belonging to a different sizo(s).</para>

	<programlisting xml:id="Isolation_1"><?xxe-sn 26yv439af40 3m?>name="tests/virtualization.cpp: Doc_Isolation_1", lines=15
	main = function:: int; entry
	{
	seq
	{
	context:: assign_sizo(domainA);
	assign_sizo_control(files).
	openFile("test")
	}
	{
	context:: assign_sizo(domainA).

	openFile("test")
	}
	{
	context:: assign_sizo(domainB);
	assign_sizo_control(files).
	openFile("test")
	}
	}</programlisting>

	<para><?xxe-sn 26yv439af40 3n?>In this example, the file <code><?xxe-sn 26yv439af40 3o?>test</code>
	is accessed from different sizos <code><?xxe-sn 26yv439af40 3p?>domainA</code>
	and <code><?xxe-sn 26yv439af40 3q?>domanB</code>. As several "competing"
	sizos are declared, they are isolated, and <code><?xxe-sn 26yv439af40 3r?>openFile</code>
	resolves <code><?xxe-sn 26yv439af40 3s?>test</code> to a different
	filename depending on which sizo it was called from. One possible way to
	implement the discussed strategy is shown below:</para>

	<programlisting xml:id="Isolation_2"><?xxe-sn 26yv439af40 3t?>name="tests/virtualization.cpp: Doc_Isolation_1", lines=15
	import raw ("scripts/cfa/context.lp"). //enable context reasoning
	import raw ("scripts/virtualization/virtualization.lp"). //enable virtualization reasoning
	import raw ("scripts/virtualization/test-Isolation_1.assembly.lp"). //additional configuration

	DictSizo = type slave dict_sizo.
	Sizo = type slave virt_sizo.

	guard:: strategy(direct)
	{
	resolveFilename = function(filename:: string):: string;
	assign_zek_access(files)
	{
	filename
	}
	}

	guard:: strategy(prefix)
	{
	resolveFilename = function(filename:: string):: string;
	assign_zek_access(files)
	{
	dictSizo = intrinsic query("dict_sizo")::[DictSizo].
	sizoId = intrinsic query late("sizo_current"->sizoCurrent:: Sizo):: int;
	demand(sizo)
	{
	loop fold(dictSizo->entry::DictSizo, 0->id):: int
	{
	if(entry[0] == sizoCurrent):: int { entry[1] } else { id }
	}
	}.

	buf = "00"::string.
	seq
	{ sprintf(buf, "%d/%s", sizoId, filename) }
	{ buf }
	}
	}

	openFile = function(filename:: string):: int
	{
	filenameReal = resolveFilename(filename):: string.
	printf("File opened: '%s'%c", filenameReal, 10)
	}</programlisting>

	<para><?xxe-sn 26yv439af40 3u?>Example outputs:</para>

	<screen xml:id="Output_Isolation_1"><?xxe-sn 26yv439af40 3v?>File opened: '0/test'
	File opened: '0/test'
	File opened: '1/test'
	</screen>

	<para><?xxe-sn 26yv439af40 3w?>In this example, the function
	<code><?xxe-sn 26yv439af40 3x?>openFile</code> calls <code><?xxe-sn 26yv439af40 3y?>resolveFilename</code>
	to find out the real filename. It can be said that <code><?xxe-sn 26yv439af40 3z?>resolveFilename</code>
	serves as <emphasis><?xxe-sn 26yv439af40 40?>hypervisor</emphasis>
	dereferencing file pseudonym into a real filename. For this purpose,
	<code><?xxe-sn 26yv439af40 41?>resolveFilename</code> consists of two
	specializations: specialization <code><?xxe-sn 26yv439af40 42?>strategy(direct)</code>
	serves the non-virtualized environment leaving the filename without any
	processing, while the other specialization <code><?xxe-sn 26yv439af40 43?>strategy(prefix)</code>
	implements the resolving strategy by adding a sizo-associated prefix to
	each file. More specifically, a unique index is assigned to each sizo, and
	<code><?xxe-sn 26yv439af40 44?>resolveFilename</code> uses the index as a
	file name prefix.</para>

	<para><?xxe-sn 26yv439af40 45?>Resolution function <code><?xxe-sn 26yv439af40 46?>resolveFilename</code>
	has only one parameter <code><?xxe-sn 26yv439af40 47?>filename</code>,
	deriving the required prefix from <emphasis><?xxe-sn 26yv439af40 48?>late
	context</emphasis> associated with a particular sizo.</para>

	<important>
	<?xxe-sn 26yv439af40 49?>

	<para><?xxe-sn 26yv439af40 4a?>Client code has no way to influence
	resolving process and force it to use an unapproved prefix, thus
	accessing and interfering with files that belong to other sizos.</para>
	</important>
	</section>

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

	<title><?xxe-sn 26yv439af40 4c?>Isolation Categories</title>

	<para><?xxe-sn 26yv439af40 4d?>Every optimization technique is applicable
	only if certain preconditions are met. Indeed, only a general approach can
	handle a general task. However, for practical instances some improvements
	are always possible by tailoring to a particular use case specifics and
	subtle details. In other words, the more information available, the more
	space there is for improvements. And the first step along this road is the
	very ability to express and reason about such additional
	information.</para>

	<para><?xxe-sn 26yv439af40 4e?>As a demonstration, in order to improve
	reasoning to find out the optimal virtualization strategy for a particular
	use case, different <emphasis><?xxe-sn 26yv439af40 4f?>sizo
	categories</emphasis> can be introduced, as below:</para>

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

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

	<para><?xxe-sn 26yv439af40 4i?><emphasis><?xxe-sn 26yv439af40 4j?>Inward
	Isolation</emphasis>. The category describes sizo that prohibits
	access of other sizos to its internal resources, but is able to access
	external resources freely. For example, monitoring and supervision
	software may have been assigned this type of isolation, where it
	freely accesses subordinate zones but cannot be influenced from the
	outside.</para>
	</listitem>

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

	<para><?xxe-sn 26yv439af40 4l?><emphasis><?xxe-sn 26yv439af40 4m?>Outward
	isolation</emphasis>. The exact opposite of inward isolation. Allows
	access from external sizos, but is only allowed to use its own
	internal resources, so no influence over the outside world is
	possible. Appropriate for various sandboxes and testing environments
	to run a potentially insecure code.</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 26yv439af40 4n?>For file operations, inward isolation may
	be implemented as a virtualization strategy that requires from
	<emphasis><?xxe-sn 26yv439af40 4o?>other</emphasis> sizos compulsory usage
	of file prefixes so that no other sizo could access internal data of
	inwardly isolated sizo. Conversely, outward isolation is compatible with
	the strategy that involves assigning a prefix for this very sizo, so it
	can in no way access any external data, being at the same time exposed to
	the outside world and any sizo that has a permission to know a unique
	assigned prefix able to access the internal data of the sizo in question.
	To put it simply, strategy for these types can be described with following
	points:</para>

	<itemizedlist>
	<?xxe-sn 26yv439af40 4p?>

	<listitem>
	<?xxe-sn 26yv439af40 4q?>

	<para><?xxe-sn 26yv439af40 4r?>Inward isolation — requires prefixes
	for other sizos.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26yv439af40 4s?>

	<para><?xxe-sn 26yv439af40 4t?>Outward isolation — requires a prefix
	for itself.</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 26yv439af40 4u?>There is an annotation introduced to
	declare a category for a current sizo:</para>

	<synopsis><?xxe-sn 26yv439af40 4v?>SYNTAX:
	assign_sizo_category(inward).
	assign_sizo_category(outward).</synopsis>

	<para><?xxe-sn 26yv439af40 4w?>Consider the example below:</para>

	<programlisting xml:id="IsolationCat_1"><?xxe-sn 26yv439af40 4x?>name="tests/virtualization.cpp: Doc_IsolationCat_1", lines=15
	test = function:: int; entry
	{
	seq
	{
	context:: assign_sizo(zoneA);
	assign_sizo_control(files);
	assign_sizo_category(inward).
	openFile("test1")
	}
	{
	context:: assign_sizo(zoneB);
	assign_sizo_control(files);
	assign_sizo_category(outward).
	openFile("test1")
	}
	}
	</programlisting>

	<para><?xxe-sn 26yv439af40 4y?>There are two sizos declared in the code
	above. Using the reasoning apparatus developed in the previous sections,
	both sizos activate virtualization, for both of them control some file
	resources and both contain <code><?xxe-sn 26yv439af40 4z?>openFile</code>
	that actually requires file access. However, this time additional bits of
	information are available, namely <code><?xxe-sn 26yv439af40 50?>zoneA</code>
	and <code><?xxe-sn 26yv439af40 51?>zoneB</code> are declared as inward and
	outward, respectively. According to the strategy outlined above,
	<code><?xxe-sn 26yv439af40 52?>zoneA</code> enables prefix based isolation
	strategy for <code><?xxe-sn 26yv439af40 53?>zoneB</code>, and
	<code><?xxe-sn 26yv439af40 54?>zoneB</code> enables isolation for itself
	as well. As a result, it is enough to virtualize only one zone
	(<code><?xxe-sn 26yv439af40 55?>zoneB</code>) leaving <code><?xxe-sn 26yv439af40 56?>zoneA</code>
	to enjoy a direct access to file resources. Example outputs are shown
	below, confirming that the direct file access is granted to
	<code><?xxe-sn 26yv439af40 57?>zoneA</code>:</para>

	<screen xml:id="Output_IsolationCat_1"><?xxe-sn 26yv439af40 58?>File opened: 'test1'
	File opened: '1/test1'
	</screen>
	</section>
	</chapter>
	<?xxe-revisions
	#2 2019-03-22T19:27:23Z Администратор
	#1 2018-12-18T13:45:06Z pgess
	1sPEAAABgaQOAIh1gZoaABWFD4NIYW9mYWZzV0lBcmRub9CxaWMnQnknc4QyAQETgT1DM1OCWAEC
	Yw8zBTMnUxljgUMjDDMGcwVTUyMMM4N7AQEjBFOBVyMFAQEzBxMFMztzDFOBHCMHEwRTCkMSIwVT
	GzMMIxhDG2OCDyMEMxRTV2MEMwhjJVMG4UMEMxFTBFOCbkMEYwVDCDMIMzdjBFMEQxEzCUMFQ4J3
	gwSTBWMYEwdTgVUzgxRDD0MWUwpTgQUBAUOCB1MIYykjBTMmc0YjBRMLYy1Tgm5jhB0TDzMgU3Rj
	DDMWEwVTBUMGUwljCCMHUxozBDMXQyFTKwEBMzpDBkMHcwZDgRtDgWVjhnJjC2MFQ2szBFMZQwUz
	HzMcQwljE0MdQxtjMDNyUyATCFMEYwhzHVMYYwVzHWMRMwRTYhMHM4E4kwVDB1MYQxAjCVMiEwkz
	D1MPY4McMx9DG1MGU4IHM2VzC2MGAQFjBVMFYwQTCSMIUwZjHlN5YzUzUkNUEwZTNjMQYwdTB0NC
	UwxTFhMJUxtDhCBDgTsjBlMEczlTIkNvYwVjDjMEQwUTBGMcQxNTjVdjgQUzHUMEQy6jEwljZ5MQ
	Uwu9Uy0jDhMFU2sBAhMLUw4BAoMJMyFDBUNcYx1TBDM0UyVDIWMuQ4FXEwdTWzOBHUMHQ4IWYxNz
	BZMGAQIzJWMcMy+TBnMFQwZzEjMZIwRTYDMKQwYTBGMNgwQjBDMGYwsTBTOBOkMFUx9zEzOCUHMF
	UyszgQgTBUMGYyMBATOCBVMFQ0MjB2NdEwdDZ2MoM4EMQw9TBBMGU1pDDiMGgwlTdpMEQxBTBmMQ
	cweDDyMQgxFDgwZTgQNjDRMFEwsTKTOGPTMhQ1BTgh1jLgECMxETBEOBdQEBYyQzbxMIQydTBDMN
	YwUzDUMekwRzHDOBKACENYM1N4JbmVwRKh2CGYFQWAieLoRev0CEBcQxgySFBoF33kO5cYp5gQIy
	nCoTM60HEB+6IYIQGJFEijRpJwaBOAmNfROacaR5iTmCfwulc5gbPRWKGQtoXIMAiRobgVmDKoMU
	zgkZgQgFggzNUDELlQCeI1gvgm+JMnWDZHgNjUilcppIjwaGY5J9CLhFHJhwOSzDCYMr3USBHR+v
	WYEQhXiJdXSBPZhMOoR8K4EbNCAzYoQ/wlq4SWyBO44YbDnDIhqaTW0/oQyBSB2DShuNbSoTHYMd
	Ia5gIoILkowgkgCgJIJnzjiHAZIchyIiezhVtERcN4IsoBMgnyyIEKRPj2OEJYQlkhK+EyGBA1yq
	WW+BTRPJWQ4gFo1cgQmrJiC/PrQ4O6iPNo0sgQiBRNM0P5dNjzlUDZURKGCQOiM2gxBHMM18gWJd
	jwGBKoIZSUQaJx6xeUZJBollG0EqinnzVRSxWoE9CtdrE6U2gUOBNNaCUy6kWCJ3Ja94gguKG0yb
	c2loKoERrjeBhSkbXrRxfyp5ep5jF3CxiVFcgmqDCIEFyW65U7RsRIZBJVWCIT6BhR4VgXclqgR5
	jHerRsQRmCq/aHlsPQ==

	-?>
	\ No newline at end of file
	+?>

No OneTemporaryActions

File Metadata

View Options

Event Timeline

No OneTemporary
Actions