No OneTemporary
Actions

Subscribers

None

File Metadata

Created: Sun, Feb 15, 5:12 PM

View Options

	diff --git a/documentation/Concepts/interpretation.xml b/documentation/Concepts/interpretation.xml
	index e102841..e5e6ec3 100644
	--- a/documentation/Concepts/interpretation.xml
	+++ b/documentation/Concepts/interpretation.xml
	@@ -1,869 +1,882 @@
	<?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 26cy4nalqsw pu35zrt1aby9?>

	<title><?xxe-sn 26cy4nalqsw pu35zrt1abya?>Interpretation</title>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1abyb?>Interpretation is a compiler's mode
	reserved to evaluate, expand and simplify parts of a given program based on
	information available in this mode. On the other hand, Interpretation is a
	middle man, or an intermediate level, between the Transcend and Brute
	levels, as it facilitates communication between those by means of
	interpreting data of respective layers. It can be further divided into Upper
	and Lower Interpretations depending on the interaction with the layer we are
	focused on at the moment.</para>

	<remark><?xxe-sn 26stp2g6sxs p?><emphasis role="bold"><?xxe-sn 26stp2g6sxs q?>mode
	whereby - как это перевести? - это режим с помощью которого xreate
	интерпретирует? Авторский смысл: это режим(компилятора) В КОТОРОМ компилятор
	интерпретирует. </emphasis></remark>

	<remark><?xxe-sn 26stp2g6sxs 1?>Program: Речь идет о компьютерной программе,
	или может приложении для смартфона, или алгоритме? Тогда лучше употребить
	соответственно software ('piece of software') / app / algorithm. Вообще
	"наши" компьютерные программы - это у них software, а не programs - -
	<emphasis role="bold"><?xxe-sn 26stp2g6sxs 2?>ДА ТУТ СЛОВО PROGRAM ПОДХОДИТ,
	особенно в контексте обработки программы с какимито целями, как здесь, чтоб
	ее интерпретировать.</emphasis></remark>

	<programlisting xml:id="Intr_1"><?xxe-sn 26cy4nalqsw pu35zrt1abyd?>name="tests/interpretation.cpp: Interpretation.Doc_Intr_1"
	main= function:: int; entry
	{
	x= "a":: string.

	y= if (x=="b"):: string; i12n(on)
	{1} else {0}.
	y
	}</programlisting>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1abye?>In this example, the identifier
	<code><?xxe-sn 26cy4nalqsw pu35zrt1abyf?>y</code> has an attached annotation
	<code><?xxe-sn 26cy4nalqsw pu35zrt1abyg?>i12(on)</code> which indicates that
	the compiler should use compile-time interpretation to evaluate
	<code><?xxe-sn 26cy4nalqsw pu35zrt1abyh?>y</code>. Once the simplification
	process is over, the function returns <code><?xxe-sn 26cy4nalqsw pu35zrt1abyi?>0</code>,
	with neither memory allocations for the string variable <code><?xxe-sn 26cy4nalqsw pu35zrt1abyj?>x</code>
	nor any computation at runtime.</para>

	<remark><?xxe-sn 26stp2g6sxs 3?>Annotation - может лучше value или
	parameter? - <emphasis role="bold"><?xxe-sn 26stp2g6sxs 4?>да Annotation
	подходит</emphasis></remark>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1abyk?>There are two annotations reserved
	to control the interpretation process:</para>

	<itemizedlist>
	<?xxe-sn 26cy4nalqsw pu35zrt1abyl?>

	<listitem>
	<?xxe-sn 26cy4nalqsw pu35zrt1abym?>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1abyn?><code><?xxe-sn 26cy4nalqsw pu35zrt1abyo?>i12n(on)</code>
	Forces compiler to interpret the annotated expression, function, or
	function argument. It yields error if the expression is impossible to
	interpret.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26cy4nalqsw pu35zrt1abyp?>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1abyq?><code><?xxe-sn 26cy4nalqsw pu35zrt1abyr?>i12n(off)</code>
	Disables interpretation for the annotated expression.</para>
	</listitem>
	</itemizedlist>

	<section>
	<?xxe-sn 26cy4nalqsw pu35zrt1abys?>

	<title><?xxe-sn 26cy4nalqsw pu35zrt1abyt?>Eligible Expressions</title>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1abyu?>Currently the compiler is able to
	interpret the following expressions:</para>

	<itemizedlist>
	<?xxe-sn 26cy4nalqsw pu35zrt1abyv?>

	<listitem>
	<?xxe-sn 26cy4nalqsw pu35zrt1abyw?>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1abyx?>Atomic instructions: numbers,
	strings, identifiers.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26cy4nalqsw pu35zrt1abyy?>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1abyz?>Relational and logic
	operators e.g. <code><?xxe-sn 26cy4nalqsw pu35zrt1abz0?>x==true</code>,
	<code><?xxe-sn 26cy4nalqsw pu35zrt1abz1?>x!=0</code>.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26cy4nalqsw pu35zrt1abz2?>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1abz3?><code><?xxe-sn 26cy4nalqsw pu35zrt1abz4?>if</code>,
	<code><?xxe-sn 26cy4nalqsw pu35zrt1abz5?>switch</code> statements.
	[[#late-interpretation-or-e\|Statement expansion]] allowed.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26cy4nalqsw pu35zrt1abz6?>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1abz7?>Loop statements.
	[[#late-interpretation-or-e\|Statement expansion]] allowed.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26cy4nalqsw pu35zrt1abz8?>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1abz9?>Functions.
	[[#function-interpretation\|Function calls]],
	[[#partial-or-late-function\|Partial function call
	interpretation]].</para>

	<remark><?xxe-sn 26stp2g6sxs 5?>interpreta - это так и нужно, или
	неполное слово? - <emphasis role="bold"><?xxe-sn 26stp2g6sxs 6?>этот
	кусок текста на сайте превратится в ссылку, это адрес ссылки, такой
	должен быть</emphasis></remark>
	</listitem>

	<listitem>
	<?xxe-sn 26cy4nalqsw pu35zrt1abza?>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1abzb?>Index operator e.g.
	<code><?xxe-sn 26cy4nalqsw pu35zrt1abzc?>x = {1, 2, 3}.
	y = x[0]</code>, <code><?xxe-sn 26t7ih8bitc 1?>info = {planet="Earth"}.
	x = info["planet"]</code>.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26cy4nalqsw pu35zrt1abze?>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1abzf?>List operators e.g.
	<code><?xxe-sn 26t7ih8bitc 2?>x = [1..10]. y={"day",
	"night"}</code>.</para>
	</listitem>
	</itemizedlist>
	</section>

	<section>
	<?xxe-sn 26cy4nalqsw pu35zrt1abzh?>

	<title><?xxe-sn 26cy4nalqsw pu35zrt1abzi?>Function Interpretation</title>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1abzj?>The whole function body may be
	subject to interpretation if it consists of interpretable expressions
	only.</para>

	<programlisting xml:id="FnIntr_1"><?xxe-sn 26cy4nalqsw pu35zrt1abzk?>name="tests/interpretation.cpp: Interpretation.Doc_FnIntr_1"
	unwrap = function(data::unknType, keys::unknType):: unknType; i12n(on)
	{
	loop fold(keys->key::string, data->record):: unknType
	{
	record[key]
	}
	}

	test = function:: bool; entry
	{
	book = unwrap({
	Library = {
	Shelf = {
	Book = "Aristotle's Politics"
	}}}, {"Library", "Shelf", "Book"}):: unknType.

	book == "Aristotle's Politics"
	}</programlisting>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1abzl?>The above example demonstrates
	the <code><?xxe-sn 26cy4nalqsw pu35zrt1abzm?>unwrap</code> function which
	is intended to be fully interpretable, as indicated by the function
	header's annotation. Obviously, the interpretable function requires that
	all its arguments are also interpretable. In this case the compiler is
	able to calculate the function's result at compile time with no byte code
	produced. Here is what the compiled code looks like (which will be also
	optimized out during the consequent compilation phases):</para>

	<programlisting xml:id="Alt_FnIntr_1"><?xxe-sn 26cy4nalqsw pu35zrt1abzn?>name="tests/interpretation.cpp: Interpretation.Doc_FnIntr_1"
	test = function:: bool; entry
	{
	book = "Aristotle's Politics":: string; i12n(on).
	book == "Aristotle's Politics"
	}</programlisting>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1abzo?>The example also reveals a number
	of similarities with dynamically typed programming languages:</para>

	<remark><?xxe-sn 26stp2g6sxs 7?>number of similarities - тут точно нужен
	артикль, неопределенный (a) если в смысле "много схожестей", и
	определенный (the) - если речь идет о точном их количестве. a dynamically
	typed - неопределенный артикль никогда не употребляется при множественных
	объектах - <emphasis role="bold"><?xxe-sn 26stp2g6sxs 8?>OK</emphasis></remark>

	<itemizedlist>
	<?xxe-sn 26cy4nalqsw pu35zrt1abzp?>

	<listitem>
	<?xxe-sn 26cy4nalqsw pu35zrt1abzq?>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1abzr?><emphasis><?xxe-sn 26cy4nalqsw pu35zrt1abzs?>Relaxed
	types</emphasis>. Notice <code><?xxe-sn 26cy4nalqsw pu35zrt1abzt?>unknType</code>
	type which has not been defined. It's interpreted well because the
	compiler completely ignores the type system since everything can be
	checked at compile time anyway. The Interpretation mode is exactly the
	level where the relaxed type system is possible without any
	performance penalties or safety concerns.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26cy4nalqsw pu35zrt1abzu?>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1abzv?><emphasis><?xxe-sn 26cy4nalqsw pu35zrt1abzw?>Introspection
	abilities</emphasis>. Notice how it is allowed to treat list fields as
	string keys, so functions like <code><?xxe-sn 26cy4nalqsw pu35zrt1abzx?>unwrap</code>
	can get list field name as a parameter. Possible errors, such as the
	list not having the requested field are easily spotted by the compiler
	during interpretation and there are no concealed runtime bugs. In a
	sense, it is a fair trade off between introspection expressiveness and
	possible compilation errors.</para>

	<remark><?xxe-sn 26stp2g6sxs 9?>no hard to catch runtime bugs - не
	вполне ясно. В смысле, "легко заметить баги проявившиеся во время
	операции"? Тогда лучше "its is easy to see runtime bugs", или может
	"the runtime bugs are possible" (если смысл такой, что могут
	проявиться ошибки/баги"). It's и другие подобные сокращения: лучше
	употреблять полную форму - it is, так как it's это разговорный вариант
	- <emphasis role="bold"><?xxe-sn 26stp2g6sxs a?>OK</emphasis>.</remark>
	</listitem>
	</itemizedlist>

	<note>
	<?xxe-sn 26cy4nalqsw pu35zrt1abzy?>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1abzz?>Additional reason for the
	arbitrary undefined type <code><?xxe-sn 26cy4nalqsw pu35zrt1ac00?>unknType</code>
	being used in the example is to ensure that no compilation occurs and
	everything is done at the interpretation mode.</para>
	</note>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1ac01?>In simple cases interpretation
	analysis could determine that a function is subject to interpretation with
	no annotation hints provided.</para>

	<programlisting xml:id="FnIntr_2"><?xxe-sn 26tbgov1xq8 1?>name="tests/interpretation.cpp: Interpretation.Doc_FnIntr_2"
	unwrap = function(data::unknType, keys::unknType):: unknType
	{
	loop fold(keys->key::string, data->record):: unknType
	{
	record[key]
	}
	}

	test = function:: bool; entry
	{
	book = unwrap({
	Library = {
	Shelf = {
	Book = "Aristotle's Politics"
	}}}, {"Library", "Shelf", "Book"}):: unknType; i12n(on).

	book == "Aristotle's Politics"
	}</programlisting>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1ac03?>The only difference from the
	example above is the lack of annotation hint for <code><?xxe-sn 26cy4nalqsw pu35zrt1ac04?>unwrap</code>.
	It can be seen that interpretation of the variable <code><?xxe-sn 26cy4nalqsw pu35zrt1ac05?>book</code>
	is required which in its turn depends on <code><?xxe-sn 26cy4nalqsw pu35zrt1ac06?>unwrap</code>.
	In this case analysis is capable enough to determine that <code><?xxe-sn 26cy4nalqsw pu35zrt1ac07?>unwrap</code>
	is indeed possible to interpret, so no errors occur.</para>

	<remark><?xxe-sn 26stp2g6sxs b?>"Developer requires interpretation" - тут
	речь о разработчике-программисте? Не вполне понятен смысл, поэтому пока
	оставляю как есть. - <emphasis role="bold"><?xxe-sn 26stp2g6sxs c?>да
	программист, исправил</emphasis></remark>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1ac08?>There are, however, more
	complicated cases for interpretation analysis:</para>

	<itemizedlist>
	<?xxe-sn 26cy4nalqsw pu35zrt1ac09?>

	<listitem>
	<?xxe-sn 26cy4nalqsw pu35zrt1ac0a?>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1ac0b?>Direct recursion.
	Interpretation analysis is able to correctly determine whether a
	function involving direct recursion (where the function calls itself)
	is subject to interpretation or not.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26cy4nalqsw pu35zrt1ac0c?>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1ac0d?>Indirect recursion.
	Currently, when processing the indirect recursion (where a function is
	called not by itself but rather by another function), the analysis
	usually fails and relies on manually provided annotation hints.</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1ac0e?>Below is an example of a direct
	recursion:</para>

	<programlisting xml:id="FnIntr_3"><?xxe-sn 26cy4nalqsw pu35zrt1ac0f?>name="tests/interpretation.cpp: Interpretation.Doc_FnIntr_3"
	unwrap = function(data:: X):: bool
	{
	if (data[0] == "the-end"):: bool
	{true} else {unwrap(data[0])}
	}

	entry = function:: bool; entry
	{
	unwrap({{{{"the-end"}}}}):: bool; i12n(on)
	}</programlisting>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1ac0g?>Function <code><?xxe-sn 26cy4nalqsw pu35zrt1ac0h?>unwrap</code>
	unwraps the nested list until the desired value is found. No function
	level annotation is required.</para>
	</section>

	<section>
	<?xxe-sn 26cy4nalqsw pu35zrt1ac0i?>

	<title><?xxe-sn 26cy4nalqsw pu35zrt1ac0j?>Late Interpretation or
	Expansion</title>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1ac0k?><emphasis><?xxe-sn 26stp2g6sxs d?>Late
	Interpretation</emphasis> can be conceptualized as a <emphasis><?xxe-sn 26stp2g6sxs e?>partial</emphasis>
	expansion, i.e. a simplification or elimination of interpretable parts of
	certain statements.</para>

	<programlisting xml:id="LateIntr_1"><?xxe-sn 26cy4nalqsw pu35zrt1ac0l?>name="tests/interpretation.cpp: Interpretation.Doc_LateIntr_1"
	test = function(x:: int):: int; entry
	{
	comm= "inc":: string; i12n(on).

	y= if (comm == "inc"):: int
	{x + 1} else {x}.
	y
	}</programlisting>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1ac0m?>In this example, computation of
	<code><?xxe-sn 26cy4nalqsw pu35zrt1ac0n?>y</code> depends on
	<code><?xxe-sn 26cy4nalqsw pu35zrt1ac0o?>comm</code> and <code><?xxe-sn 26cy4nalqsw pu35zrt1ac0p?>x</code>.
	On the one hand, <code><?xxe-sn 26cy4nalqsw pu35zrt1ac0q?>comm</code> has
	an annotation that requires interpretation, while on the other hand
	<code><?xxe-sn 26cy4nalqsw pu35zrt1ac0r?>x</code> is unknown at the
	compile-time and thus cannot be interpreted. In this case the only way to
	satisfy contradictory requirements is to <emphasis><?xxe-sn 26cy4nalqsw pu35zrt1ac0s?>expand</emphasis>
	the <code><?xxe-sn 26cy4nalqsw pu35zrt1ac0t?>if</code> statement, since it
	is only possible to interpret condition part of the statement, leaving
	conditional blocks unchanged. In other words, the <code><?xxe-sn 26cy4nalqsw pu35zrt1ac0u?>if</code>
	statement is <emphasis><?xxe-sn 26cy4nalqsw pu35zrt1ac0v?>expanded</emphasis>
	which results in only one of the child blocks being compiled,
	<code><?xxe-sn 26cy4nalqsw pu35zrt1ac0w?>x+1</code> in this example, based
	on already known fact that the <code><?xxe-sn 26stp2g6sxs f?>else</code>
	block would never be executed.</para>

	<remark><?xxe-sn 26stp2g6sxs g?>"to interpret condition part of the
	statement" - это не смог понять. - <emphasis role="bold"><?xxe-sn 26stp2g6sxs h?>`if
	(...) {..} else {...}` is a statement. It consists of condition part `if
	(..)`, and two blocks - "if-true" block and "if-false" block
	</emphasis></remark>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1ac0x?>Due to the fact that expansion,
	as opposed to "pure interpretation", leaves some portion of the code for
	subsequent compilation it can also be called <emphasis><?xxe-sn 26cy4nalqsw pu35zrt1ac0y?>late
	interpretation</emphasis> for the result depends on runtime information
	and has memory and performance footprint.</para>

	<remark><?xxe-sn 26stp2g6sxs i?>as having runtime footprint - не понял.
	Что-то связанное с требованиями к памяти? Но это кажется о программах, а
	не о interpretation - <emphasis role="bold"><?xxe-sn 26stp2g6sxs j?>переписал
	фразу</emphasis></remark>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1ac0z?>Below is a more complex example
	of a loop expansion:</para>

	<programlisting xml:id="LateIntr_2"><?xxe-sn 26cy4nalqsw pu35zrt1ac10?>name="tests/interpretation.cpp: Interpretation.Doc_LateIntr_2"
	main = function(x:: int):: int; entry
	{
	commands = {"inc", "double", "dec"}:: [string]; i12n(on).

	loop fold(commands->comm::string, x->operand):: int
	{
	switch(comm):: int
	case ("inc") {operand + 1}
	case ("dec") {operand - 1}
	case ("double") {operand * 2}
	}
	}
	</programlisting>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1ac11?>Identifier <code><?xxe-sn 26cy4nalqsw pu35zrt1ac12?>commands</code>
	contains a list of operations that need to be interpreted as indicated by
	the corresponding annotation. Operand <code><?xxe-sn 26cy4nalqsw pu35zrt1ac13?>x</code>
	is assigned at runtime. This is the same situation as in previous example,
	and it triggers expansion as expected. The result after expansion looks as
	follows:</para>

	<programlisting xml:id="Alt_LateIntr_2"><?xxe-sn 26cy4nalqsw pu35zrt1ac14?>name="tests/interpretation.cpp: Interpretation.Doc_LateIntr_2"
	main = function(x:: int):: int; entry
	{
	x{1} = x + 1:: int.
	x{2} = x{1} * 2:: int.
	x{3} = x{2} * 1:: int.
	x{3}
	}</programlisting>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1ac15?>In other words, this mimics the
	well known loop unrolling technique by putting several copies of the loop
	body in a row, each one for every item in the list <code><?xxe-sn 26stp2g6sxs k?>commands</code>.</para>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1ac16?>As of now, the following
	statements support late interpretation:</para>

	<itemizedlist>
	<?xxe-sn 26cy4nalqsw pu35zrt1ac17?>

	<listitem>
	<?xxe-sn 26cy4nalqsw pu35zrt1ac18?>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1ac19?>Branching statements:
	<code><?xxe-sn 26cy4nalqsw pu35zrt1ac1a?>if</code>, <code><?xxe-sn 26cy4nalqsw pu35zrt1ac1b?>switch</code>,
	<code><?xxe-sn 26cy4nalqsw pu35zrt1ac1c?>switch variant</code>,
	<code><?xxe-sn 26cy4nalqsw pu35zrt1ac1d?>switch late</code>.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26cy4nalqsw pu35zrt1ac1e?>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1ac1f?>Loop statements:
	<code><?xxe-sn 26cy4nalqsw pu35zrt1ac1g?>loop fold</code>.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26cy4nalqsw pu35zrt1ac1h?>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1ac1i?>Functions.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26cy4nalqsw pu35zrt1ac1j?>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1ac1k?>Other operators:
	<code><?xxe-sn 26cy4nalqsw pu35zrt1ac1l?>query late</code>.</para>
	</listitem>
	</itemizedlist>
	</section>

	<section>
	<?xxe-sn 26cy4nalqsw pu35zrt1ac1m?>

	<title><?xxe-sn 26cy4nalqsw pu35zrt1ac1n?>Partial or Late Function
	Interpretation</title>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1ac1o?>Xreate supports cases where a
	function has mixed arguments in terms of interpretation, some of which
	need to be interpreted, while others need to be compiled.</para>

	<programlisting xml:id="LateFnIntr_1"><?xxe-sn 26cy4nalqsw pu35zrt1ac1p?>name="tests/interpretation.cpp: Interpretation.Doc_LateFnIntr_1"
	evaluate= function(argument:: num, code:: string; i12n(on)):: num
	{
	switch(code):: num
	case ("inc") {argument + 1}
	case ("dec") {argument - 1}
	case ("double") {argument * 2}
	case default {argument}
	}

	main = function(init::int):: int; entry
	{
	commands= {"inc", "double", "dec"}:: [string]; i12n(on).

	loop fold(commands->comm::string, init->operand):: int
	{
	evaluate(operand, comm)
	}
	}</programlisting>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1ac1q?>Looking at the function
	<code><?xxe-sn 26cy4nalqsw pu35zrt1ac1r?>evaluate</code>'s signature in
	this example we can see only one argument <code><?xxe-sn 26cy4nalqsw pu35zrt1ac1s?>code</code>
	that requires interpretation. This means that the function <code><?xxe-sn 26cy4nalqsw pu35zrt1ac1t?>evaluate</code>
	is subject to a partial interpretation or, in other words,
	<emphasis><?xxe-sn 26cy4nalqsw pu35zrt1ac1u?>late function
	interpretation</emphasis>.</para>

	<para><?xxe-sn 26stp2g6sxs n?>In general, to enable late interpretation
	for a function, at least one of its arguments should be annotated as
	<code><?xxe-sn 26cy4nalqsw pu35zrt1ac1v?>i12n(on)</code>. What compiler
	does next is to generate a number of distinctive <emphasis><?xxe-sn 26cy4nalqsw pu35zrt1ac1w?>function
	specializations</emphasis>. Each unique combination of interpretable
	argument values corresponds to its own function specialization. This
	should be used with cautiousness, since compiler can generate large
	amounts of code in some cases.</para>

	<remark><?xxe-sn 26stp2g6sxs l?>What compiler does next is to generate
	number - то же самое, что в примеч. ниже (a number - несколько, the number
	- конкретное число).To enable late interpretation for function - тут перед
	function обязательно нужен артикль - определенный (the), если речь идет о
	evaluate, или неопределенный (а) если речь идет о любой функции (я указал
	the) - <emphasis role="bold"><?xxe-sn 26stp2g6sxs m?>OK</emphasis></remark>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1ac1x?>Based on the above example, three
	different <code><?xxe-sn 26cy4nalqsw pu35zrt1ac1y?>evaluate</code>
	specializations are generated as follows:</para>

	<programlisting xml:id="Alt_LateFnIntr_1"><?xxe-sn 26cy4nalqsw pu35zrt1ac1z?>name="tests/interpretation.cpp: Interpretation.Doc_LateFnIntr_1"
	main= function(init::int):: int; entry
	{
	operand = init:: int.

	operand{1} = evaluate1(operand):: int.
	operand{2} = evaluate2(operand{1})::int.
	operand{3} = evaluate3(operand{2})::int.

	operand(3)
	}</programlisting>
	</section>

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

	- <title><?xxe-sn 2f6e093xhxc 2?>Transcend and Interpretation</title>
	+ <title><?xxe-sn 2f6e093xhxc 2?>Queries</title>

	<synopsis><?xxe-sn 2f6e093xhxc 3?>SYNTAX:
	intrinsic query (//predicate//):: type; [//annotations-list//]</synopsis>

	<itemizedlist>
	<?xxe-sn 2f6e093xhxc 4?>

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

	<para><?xxe-sn 2f6e093xhxc 6?><emphasis><?xxe-sn 2f6e093xhxc 7?>predicate</emphasis>
	Denotes a Transcend predicate.</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 2f6e093xhxc a?>Represents the value of the Transcend
	predicate <emphasis><?xxe-sn 2f6e093xhxc b?>predicate</emphasis> in the
	format as follows:</para>

	<itemizedlist>
	<?xxe-sn 2f6e093xhxc g?>

	<listitem>
	<?xxe-sn 2f6e093xhxc h?>

	<para><?xxe-sn 2f6e093xhxc i?>If a predicate has only one argument,
	returns a list of elements of an appropriate type: <code><?xxe-sn 2f6e093xhxc j?>int</code>,
	<code><?xxe-sn 2f6e093xhxc k?>string</code>, variant or tuple.</para>
	</listitem>

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

	<para><?xxe-sn 2f6e093xhxc m?>in case of several arguments, the
	arguments comprise a record. The function returns a list of
	records.</para>
	</listitem>

	<listitem>
	<?xxe-sn 2f6e093xhxc n?>

	<para><?xxe-sn 2f6e093xhxc o?>Predicates correspond to
	variants.</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 2f6e093xhxc 8?>Interpretation can be viewed as the middle
	ground between high level Transcend and low level Brute. In essence, the
	principal role of Interpretation is to serve as a link between them by
	<emphasis><?xxe-sn 2f6e093xhxc 9?>interpreting</emphasis> data for Brute
	from Transcend. The special built-in function <code><?xxe-sn 2f6e093xhxc c?>intrinsic query</code>
	is provided to query data from Transcend allowing to process it
	further.</para>

	<para><?xxe-sn 2f6e093xhxc d?>As a short example, assume that we have
	Transcend facts as follows:</para>

	<programlisting><?xxe-sn 2f6e093xhxc e?>person("Ben").</programlisting>

	<para><?xxe-sn 2f6e093xhxc f?>This data can be queried as below:</para>

	<programlisting><?xxe-sn 2f6e093xhxc p?>Persons = type [string]. //we expect a list of strings
	persons = function:: Persons
	{
	intrinsic query("person"):: Persons
	}</programlisting>

	<para><?xxe-sn 2f6e093xhxc q?>The <code><?xxe-sn 2f6e093xhxc r?>persons</code>
	function in this example returns a list of persons supplied by Transcend.
	The example can be slightly rewritten using <link
	xlink:href="/d/syntax/#slave-types"><?xxe-sn 2f6e093xhxc s?>slave
	types</link> which are reserved to automatically identify an appropriate
	type for the returned value. The next excerpt is equivalent to the
	previous one:</para>

	<programlisting><?xxe-sn 2f6e093xhxc t?>Person = type slave person. //equivalent to string
	Persons = type [Person]

	persons = function:: Persons
	{
	intrinsic query("person"):: Persons
	}</programlisting>
	+ </section>
	+
	+ <section>
	+ <?xxe-sn 2fxwo1r89a8 2?>

	- <para><?xxe-sn 2f6e093xhxc u?>Querying allows to use powerful Transcend
	+ <title><?xxe-sn 2fxwo1r89a8 3?>Querying Example: GUI</title>
	+
	+ <para><?xxe-sn 2fxwo1r89a8 5?>Querying allows to use powerful Transcend
	capabilities to solve convoluted problems, consequently retrieving
	reasoning solutions by Brute for efficient processing. Consider a more
	complicated example dealing with a GUI.</para>

	- <para><?xxe-sn 2f6e093xhxc v?>First, let us start off defining more or
	- less semantically an application's GUI on Transcend level:</para>
	+ <para><?xxe-sn 2fxwo1r89a8 6?>First, let us start off defining more or
	+ less semantically an application's GUI on the Transcend level:</para>

	- <programlisting xml:id="IntrinsicQuery_2_GUI"><?xxe-sn 2f6e093xhxc w?>name="tests/association.cpp: Association.Doc_IntrinsicQuery_2", lines=15
	+ <programlisting xml:id="IntrinsicQuery_2_GUI"><?xxe-sn 2fxwo1r89a8 7?>name="tests/association.cpp: Association.Doc_IntrinsicQuery_2", lines=15
	%Layout consists of two blocks:
	block(my_content; my_nav).

	%Assign roles to the blocks:
	role(my_content, body).
	role(my_nav, navigation).

	%Navigation block can be in either an iconized or expanded form:
	form(none; expanded; iconized).
	allowed_form(my_nav, (expanded; iconized)).

	%Visual theme:
	background(my_content, color(blue)).
	background(my_nav, color(grey)).</programlisting>

	- <para><?xxe-sn 2f6e093xhxc x?>Above we have described GUI consisting of
	+ <para><?xxe-sn 2fxwo1r89a8 8?>Above we have described GUI consisting of
	two blocks: main content and navigation blocks. The same application can
	- look differently depending on platform or viewport properties. Let us
	+ look differently depending on a platform's or viewport properties. Let us
	define a platform:</para>

	- <programlisting xml:id="IntrinsicQuery_2_Platform"><?xxe-sn 2f6e093xhxc y?>name="tests/association.cpp: Association.Doc_IntrinsicQuery_2", lines=15
	+ <programlisting xml:id="IntrinsicQuery_2_Platform"><?xxe-sn 2fxwo1r89a8 9?>name="tests/association.cpp: Association.Doc_IntrinsicQuery_2", lines=15
	% The height is greater than the viewport's width:
	orientation(portrait).</programlisting>

	- <para><?xxe-sn 2f6e093xhxc z?>Having an application's semantic description
	+ <para><?xxe-sn 2fxwo1r89a8 a?>Having an application's semantic description
	as well as a platform's description we can now combine them using
	additional rules to produce the final result: how the application should
	look like on the given platform.</para>

	- <programlisting xml:id="IntrinsicQuery_2_Rules"><?xxe-sn 2f6e093xhxc 10?>name="tests/association.cpp: Association.Doc_IntrinsicQuery_2", lines=15
	+ <programlisting xml:id="IntrinsicQuery_2_Rules"><?xxe-sn 2fxwo1r89a8 b?>name="tests/association.cpp: Association.Doc_IntrinsicQuery_2", lines=15
	% Portrait orientation rules:

	%Determine appopriate navigation list's form:
	form(Nav, iconized):-
	orientation(portrait);
	allowed_form(Nav, iconized);
	role(Nav, navigation).

	%Determine blocks' layout:
	align(Nav, bottom_of(Body)):-
	orientation(portrait);
	role(Nav, navigation);
	role(Body, body).

	% Landscape orientation rules:
	form(Nav, expanded):-
	orientation(landscape);
	allowed_form(Nav, expanded);
	role(Nav, navigation).

	align(Nav, left_of(Body)):-
	orientation(landscape);
	role(Nav, navigation);
	role(Body, body).</programlisting>

	- <para><?xxe-sn 2f6e093xhxc 11?>In short, the rules above read that we
	- place the expanded navigation block <code><?xxe-sn 2f6e093xhxc 12?>my_nav</code>
	- and the content block <code><?xxe-sn 2f6e093xhxc 13?>my_content</code> in
	- a row for wide displays; conversely, <code><?xxe-sn 2f6e093xhxc 14?>my_content</code>
	- and iconized <code><?xxe-sn 2f6e093xhxc 15?>my_nav</code> on top of each
	+ <para><?xxe-sn 2fxwo1r89a8 c?>In short, the rules above read that we place
	+ the expanded navigation block <code><?xxe-sn 2fxwo1r89a8 d?>my_nav</code>
	+ and the content block <code><?xxe-sn 2fxwo1r89a8 e?>my_content</code> in a
	+ row for wide displays; conversely, <code><?xxe-sn 2fxwo1r89a8 f?>my_content</code>
	+ and iconized <code><?xxe-sn 2fxwo1r89a8 g?>my_nav</code> on top of each
	other for narrow displays.</para>

	- <para><?xxe-sn 2f6e093xhxc 16?>After Transcend has decided actual forms
	- and blocks alignment, the next step is to retrieve solutions denoted by
	- the <code><?xxe-sn 2f6e093xhxc 17?>align</code> and <code><?xxe-sn 2f6e093xhxc 18?>form</code>
	+ <para><?xxe-sn 2fxwo1r89a8 h?>After Transcend has decided actual forms and
	+ blocks alignment, the next step is to retrieve solutions denoted by the
	+ <code><?xxe-sn 2fxwo1r89a8 i?>align</code> and <code><?xxe-sn 2fxwo1r89a8 j?>form</code>
	predicates and to actually draw GUI elements:</para>

	- <programlisting xml:id="IntrinsicQuery_2_Code"><?xxe-sn 2f6e093xhxc 19?>name="tests/association.cpp: Association.Doc_IntrinsicQuery_2", lines=15
	+ <programlisting xml:id="IntrinsicQuery_2_Code"><?xxe-sn 2fxwo1r89a8 k?>name="tests/association.cpp: Association.Doc_IntrinsicQuery_2", lines=15
	//Define types:
	Block = type slave block.
	Role = type variant {body, navigation}.
	Alignment = type variant{
	bottom_of:: Block,
	left_of::Block
	}.
	Layout = type {Role, Alignment}.

	//Determine role and form:
	drawBlock = function(block:: Block):: Drawing
	{
	forms = intrinsic query ("form"):: [Form].
	formCurrent = getBlockForm(forms, block):: Form.

	roles = intrinsic query ("role"):: [Role].
	roleCurrent = getBlockRole(block):: Role.

	switch variant (roleCurrent):: Drawing
	case (body)
	{drawBody(formCurrent)}

	case (navigation)
	{drawNavigation(formCurrent)}
	}

	//Determine layout
	draw = function:: Drawing; entry
	{
	layout = intrinsic query ("layout"):: Layout.
	blockA = layout[0]:: Block.

	switch variant (layout[1]->blockB):: Drawing
	case (bottom_of)
	{drawVerical(blockA, blockB)}

	case (left_of)
	{drawHorizontal(blockA, blockB)}
	}</programlisting>

	- <para><?xxe-sn 2f7yw0s6vb4 1?>Notice that the <code><?xxe-sn 2f7yw0s6vb4 2?>draw</code>
	- and <code><?xxe-sn 2f7yw0s6vb4 3?>drawBlock</code> functions work with
	+ <para><?xxe-sn 2fxwo1r89a8 l?>Notice that the <code><?xxe-sn 2fxwo1r89a8 m?>draw</code>
	+ and <code><?xxe-sn 2fxwo1r89a8 n?>drawBlock</code> functions work with
	compile time data from Transcend, thus all this code after interpretation
	gets simplified into the following:</para>

	- <programlisting><?xxe-sn 2f7yw0s6vb4 4?>drawVertical(drawBody(none()), drawNavigation(iconized())).</programlisting>
	+ <programlisting><?xxe-sn 2fxwo1r89a8 o?>drawVertical(drawBody(none()), drawNavigation(iconized())).</programlisting>

	- <para><?xxe-sn 2f7yw0s6vb4 5?>The example above demonstrates the
	- possibility to delegate to Transcend <emphasis><?xxe-sn 2f7yw0s6vb4 6?>intelligent
	+ <para><?xxe-sn 2fxwo1r89a8 p?>The example above demonstrates the
	+ possibility to delegate to Transcend <emphasis><?xxe-sn 2fxwo1r89a8 q?>intelligent
	tasks</emphasis>, such as adapting a GUI to a particular platform, and
	leaving Brute with efficient implementation matters.</para>
	</section>

	<section>
	<?xxe-sn 26cy4nalqsw pu35zrt1ac20?>

	<title><?xxe-sn 26cy4nalqsw pu35zrt1ac21?>Domain Specific Languages and
	Interpretation</title>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1ac22?>DSL is an idea of expressing
	various concepts in a lapidary and concise form. Xreate recognizes and
	acknowledges very successful and beneficial DSL usage in certain areas,
	primarily to express <emphasis><?xxe-sn 26cy4nalqsw pu35zrt1ac23?>queries</emphasis>
	and <emphasis><?xxe-sn 26cy4nalqsw pu35zrt1ac24?>configs</emphasis>, to
	name a few. It is possible to use interpretation abilities to emulate DSL.
	Developer can express the desired functionality in the form of nested
	lists of numbers, variants and strings which are then processed by a
	partially interpreted function. Such function in its turn transforms the
	input data into a set of low level compilation instructions so there is no
	runtime overhead.</para>
	</section>

	<section>
	<?xxe-sn 26cy4nalqsw pu35zrt1ac25?>

	<title><?xxe-sn 26cy4nalqsw pu35zrt1ac26?>On Interpretation
	Analysis</title>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1ac27?>Analysis follows classical
	<emphasis><?xxe-sn 26stp2g6sxs o?>type reconstruction</emphasis>
	algorithms to determine which expressions are subject to interpretation
	and check the correctness of reconstruction w.r.t. developer-provided
	annotations. Analysis consists of two general parts:</para>

	<itemizedlist>
	<?xxe-sn 26cy4nalqsw pu35zrt1ac28?>

	<listitem>
	<?xxe-sn 26cy4nalqsw pu35zrt1ac29?>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1ac2a?><emphasis><?xxe-sn 26cy4nalqsw pu35zrt1ac2b?>Inference</emphasis>.
	Infers if it is possible to interpret an expression based on its
	already inferred argument's decisions.</para>
	</listitem>

	<listitem>
	<?xxe-sn 26cy4nalqsw pu35zrt1ac2c?>

	<para><?xxe-sn 26cy4nalqsw pu35zrt1ac2d?><emphasis><?xxe-sn 26cy4nalqsw pu35zrt1ac2e?>Unification</emphasis>.
	Assigns an appropriate decision w.r.t. previously inferred
	expectations and developer-provided hints as well.</para>
	</listitem>
	</itemizedlist>
	</section>
	</chapter>
	<?xxe-revisions
	+#10 2019-05-28T10:00:12Z pgess
	#9 2019-05-16T14:57:00Z pgess
	+1sPEAAABgoFMAIIugoB4ABmBK2J1dnd5ejIzNDU3ODd5dzBzNnZiNDIzNDU2c4G0YxMOExhDlTZj
	+GwEBM4F3UwoBAUNVY1JzCgEBM4NdcwoTBDMFU4ELUwhTeXMKAQEzgThzCgEBU4IecwsTD0M+M4RG
	+cwsTBzNZcwsBAWM5cwsBAUNPcwsBAWM0cwsBAUNUcwsTBBMFY4EBcwsBAWMmcwsBAUN/cwsTBDNI
	+Y4d9AQkTBDMHQxojCwEBUyVjCgEBM4E5cwoBAVNhcwoBARMFM1tzCgEBY5ENAIYmg3iBrk6MZ4lW
	+gbA+ggJZNl02ohSVaINwhS+BFzaBBDaBQzaBhn6aQYJ1NtV4hFc2ZDZENlo2PzaBkkqBjU1nNoEM
	+NjE2zWiaNoFVi1W5fbclL+99ATCygUSymXNxsmY=
	+
	#8 2019-05-15T14:56:03Z pgess
	1sPEAAABgoB4AC2CgHcAABQSc4HLSiMEE4tOEwcTB1MHMyFDqSUAgdY4gctKga9vhRKHQexAhEg=
	-
	#7 2019-05-14T17:52:28Z pgess
	1sPEAAABgoB7AINMgfUKABqBcYE4LiBBaXc/PmZ5Pz4lIEhsb25nZW50ZXh0OSBzgbxmE4NIEwQT
	CkMEYwUBA1MJUwlDG1OCYRMKYxFjgi8zgVtTBxMGQ4JQEwRjBlMMQwYBAWMMQwQzBTMIQwYzBWNE
	QwUTCWMGcwpjBzMFQwVDBFMEY4EmIxYBA0M8Y0VjdUMZUxZTCDMMYzpTgQEBAWNTgxYBBjMJ3QEC
	Y4EyM4EPgxZDBGMGAQEzhGwTB0NmExFjggpDBEMQqTMLMwxzEVMMQ1FDBTMHUwQTCIMKgxFTFeFj
	CFMPYxEzF0MFQxxjSnMFMxxTRmMcIwkTCDNqkwUTFiMOcwcBAWMRcwUzF1NBYxsjCXMIEwgzbRMU
	M496AIG8aNt9hiaPBQ7kTzqBnh4smj2CDGuCOsJWljiBaYR/kBuBk2ueRpJ4qQX2NpgUiUHRKrFs
	ozS4C6AUJoEBcoHZB5QfhRWBsAKJT4Imgik6eDoMIoECP4ECaoFfDguBN2qBRU0HgaRIhHKTb32Q
	PoJNh3iBw2GBlDLvmAuWCV2sN41igbovPZKBmW+pEKBqgU8QEJBUGx0/Th1PAYHlbCQ/gcRYAeyD
	ST8VGEoB7IGfayuBiiiGKg==
	#6 2018-12-15T16:59:22Z pgess
	1sPEAAABgfUPABeBxBEAAAkHc4G0NSMWI49GAIG8f4HEEQ==
	#5 2018-12-15T16:52:17Z pgess
	1sPEAAABgcQRADKBw2wAABoRc6Y2IwkTgR+DCYNeM0RDBBMLQx4TCDOBmi4A3R2mTqpOghXYbqY6
	UpIdLg==
	#4 2018-12-15T16:19:00Z pgess
	1sPEAAABgcNsAEyBw2AAACYfc8wdExoTkBhDCmMEEwRTG1M3EwljhFITF0MlQ+BbUxVDEFMLMwsA
	zUnMM5IgrEa+b5AnJJckN4sitEqFIJF9gXKROuEM
	#3 2018-12-15T14:05:19Z pgess
	1sPEAAABgcNhAIVpgb9cADODNIF5ZD8+PSB7MSwgMiwgPSA9ID0ga2MwMj8+NC0gMXB6MT0gICsg
	MTIqIDIzLTF9KDEpMygyc5EoEyEBA0MUIwtTBzMGMwpTC2MSMxdDElMFIzhjmhYBCUMFAQJTDmMj
	AQIzEyMEQ4E1AQJjgnczIQEBQwgzMGMZM0dTCEMRYz0zEkMWUxZjGCMIMyJTNGMIEwVjIpM4U4Qm
	gyAzBEMEYzKTEpMJUzMTBGOYfYMfAQUjBjM0Mw2TCGNLIw6TEWMHYwcjBZMEkzKTDpMOEwRjECMI
	UxIjCjMSIwxzIiMJMy+DCGMKcwVjCUMcIwZDN2ONe4MfUwUjGDMMUwaTBjMuQ0lTDhMEY4Vdgx9D
	BVMEgwxjF3MEUxpzEHMFMxpjCDMYcwUjOkOSGoMfMwVzBIMMcwxTI3MEU0kzPpMIUzBzCGMmQyZT
	JGODYiMhAQFDHTMLcwQzDkMFUxEzBGMO7ZMGMzxDjFpDIQEBUwoTCkMxcwRDPWMGMyNDI1MjYw8z
	RCMbQ0NjQpMIMx6TP1OONnMhAQFzCgEDUwmDDxMEMwRzBAEBUwrNEwgBASMxAQOTBJMIAQGDMdVz
	DjMOgwtzBEMJkwljBzMFkwoBAkMUcwSTDDMTAQMjDwEBQwszCQECUwhDDGMFgxQTM1OPRgCDKY5u
	xjQX2CsKFAkUFRDMNTyaJAoPKL8zGoE6h3kig3AuF9A2Sg87EBIQARgejyuSUkH5WamEXI45ozrM
	3IdgkwxBqaJGoGOBA1QZVYKCHV8R4pzM5ygWARABEgEWgV8j36YoUqUcpCilV0GkSamOLJJiWoE4
	WQQqR5I2EamGEI4581Q2GmlSLxwEjpcqVKmSTRfzQ142JkdUBKg2IiIihwAiy1U2/EQeA1YgjLv2
	a2GSMSKSG41nNjQ/BCEhIRKXO1xBVEb0Wk1vlwEDkmQtNopXojCEaUGUaSgyF4GNdck2kmIf/QBW
	bjGMbg0nEDUWAiCxgZoESw==
	#2 2018-12-15T11:27:17Z pgess
	1sPEAAABgb9cAIE1gb9cAARlRXpkLmdznFkTgVyTFUODOJM/Y4FCkz5DgVOTPmMuQwVjNpM+Q4Eh
	EyZDgxVjBGNrExQBAkMrAQFTCJM+Yy4TBEM3AQFTICMecxBD1zkzJkOKFVM/U3mDbBMIQz5DfJMV
	cxAzi14TBGOddwCcWlqBclqDeFqCAVqCEoxBgR1agSiIL4FItBSDGYM1dpAgWnKRIIYrX4FRTE7C
	IZVJi0+KVa6RUs4vgTNaTIEihhaLYg==
	#1 2018-12-07T16:28:26Z Acer2
	1sPEAAABgb9gAIckgbYGAEGDeoJgeWNzIHdhcnJpYzJmZ29jMjJpMmtob25vJ3MybWMybj8+SW9w
	MnI/PjJ0SUZjMnZjMnhnZW9mIGBgMzMxYzJ6Pz5zhE0TDSMHQyoBAkMLUw0TEGMHEwgBATMIIwdD
	BiMEYwlDBUMRYwRTBmMNMwZTBUMEMwYjBbXbE4JtQyQBAyMpAQFTgxUjCWMJEwZDQEOETgEBU2Bj
	J4MkAQIzBEMlAQIzPJMJkywzj3gjJlMpAQKTT5MJkwgTNVOLUTMEUxkzgT9jB1MJYwSDB0MHAQJD
	BAECMwVTCBMIAQJDBVM0MwQzg0ZzJhMEgyUBAlOCC5MaExMBBVOBI5MJkwhDhCAzCBMHExGTNUOC
	MgEBYwaTBEMHQwZTCEMNYwRjBRMEQwUTCJMFMwdjBFMekwkjJgEBUykBATOCe5MJkwiDJhMEUyUB
	BDOBPiMKkwiTDEMQg4IaMwdjBFMNUwUTBZMJk0ETDkMJU4Z6YwljD0NHM2RDCUMLEw8TJTMXUzMj
	JkMEgyUBAmOBVJMJky5jMoMOIwlTgTSTCYOBEmM+Y4E/kwlDPhMVcxBjhUhTCWMJgzxjBXMJQwZT
	CEMIY4dcAQITEmOBLiMUIwQzK0OBG0MmEwYzBVMiIyZjKAEDQ1WTCZMuM4FnYxuDMBMoAQNjgUqT
	CZMuY4USU3kBAjMFY4QerPlTC0OTOkMiYwRDg2eTJdMjJQECM4E2kwmTCJMmEygBBZOCOZMJky1D
	jVEzE0ODV4MGUwkTCIMEEw2DPlOCHACJB6x4vjugO4xKhQ+nIIRpCJAODpEOCMRQEZIJqwoRhEGP
	QJRehmW9d9Bwnm2FS5ZljgSGDKs7gj6FGYVKSIRUYaCZG7xbRbbegUmROsEJwrbenGOCZo1ii1cb
	myGNMacvzp5AVpN80nSRUwyoIY9CPJ+aMfuDZLaDNYINtt6BboQsukKXNGNZhHuh3AGCValMEMQ0
	khq5Ra1AhEsSl1yrTq4ntoxnJ4Evtt4wnUO6HbE3hXjeY4FooNcerGiZGJAWhhO23oN4ljZYtFWQ
	docWU9wJhwnUPZMriRgejyuLWftRtt6CXviEL0koqLALgVEogUycWktkhV+pZ/g3iMcDsnSlAIFs
	pVaHcIFCk2jQC4FxgRyFVIFhV5pmwUFAtt6CToJnjaEkgmW23oJWhRWdZX6GVIYP6GKEWJlNrkiU
	ER+IUpdyhAW23h+iQsm23oMpjXQfYYN3xkzBuF+zjAM=
	?>
	\ No newline at end of file
	diff --git a/documentation/Transcend/transcend.xml b/documentation/Transcend/transcend.xml
	index 26d6895..757e703 100644
	--- a/documentation/Transcend/transcend.xml
	+++ b/documentation/Transcend/transcend.xml
	@@ -1,578 +1,578 @@
	<?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 a
	process of reasoning about a program in order to influence final compilation
	results.</para>

	<para><?xxe-sn 2ajela3ur5s 7t?>First, the compiler extracts
	<emphasis><?xxe-sn 2ajela3ur5s 7u?>annotations</emphasis> from a source code
	as well as other <emphasis><?xxe-sn 2ezs03nkiyo 4?>logic facts</emphasis>
	from a number of different sources. Second, logic facts are coupled with
	<emphasis><?xxe-sn 2ezs03nkiyo 5?>logic rules</emphasis>, that describe how
	to process input data, to form a complete <emphasis><?xxe-sn 2ezs03nkiyo 6?>logic
	program</emphasis>. Finally, a solver processes the logic program and
	produces decisions that affect and control compilation in a number of ways.
	Crucial difference of annotations from language keywords is that they do not
	have any predefined meaning and semantic; only custom developer provided
	rules make them matter.</para>

	<para><?xxe-sn 2ezs03nkiyo 7?><phrase condition="clasp"><?xxe-sn 2ezs03nkiyo 8?>Currently,
	an external logic solver Clasp is used to perform Transcend tasks. Hence,
	logic rules are written(and annotations are converted to) in the ASP format:
	one of standard first order logic notations.</phrase></para>

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

	<title><?xxe-sn 2f0cduzin5j -wunr7fl0rw84?>Reasoning Solutions</title>

	<para><?xxe-sn 2f0cduzin5j -wunr7fl0rw83?>Transcend prepares solutions to
	verify, control and guide compilation process. For each uncertain
	situation the compiler consults reasoning solutions to know how to
	proceed. Thus, many compilation aspects are delegated to Transcend and are
	ultimately exposed to a software developer. Transcend solution are used in
	a number of ways as follows:</para>

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

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

	<para><?xxe-sn 2f0cduzin5j -wunr7fl0rw80?><link
	- xlink:href="/d/concepts/interpretation/#transcend-and-interpreta"><?xxe-sn 2fadpf0i3zr -wunr7fl0rw8v?>Direct
	+ xlink:href="/d/concepts/interpretation/#queries"><?xxe-sn 2fadpf0i3zr -wunr7fl0rw8v?>Direct
	connection</link> via the <code><?xxe-sn 2fadpf0i3zr -wunr7fl0rw8u?>query</code>
	built-in function. A program can request and explicitly process
	received data from Transcend as it sees fit.</para>
	</listitem>

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

	<para><?xxe-sn 2f0cduzin5j -wunr7fl0rw7x?><link
	xlink:href="/d/concepts/polymorphism/"><?xxe-sn 2f0cduzin5j -wunr7fl0rw7w?>Function
	level polymorphism</link>. This is the principal way for Transcend to
	interfere in compilation. Polymorphism is based on a possibility for a
	function to have several specializations. Each time the function is
	invoked in a client code, Transcend decides which exactly
	specialization to call. This gives a deep control over final program
	behaviour.</para>
	</listitem>

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

	<para><?xxe-sn 2f0cduzin5j -wunr7fl0rw7u?><link
	xlink:href="/d/syntax/modules/"><?xxe-sn 2f0cduzin5j -wunr7fl0rw7t?>Module
	level polymorphism</link>. Transcend decides which modules to choose
	that satisfy a client code's requirements.</para>
	</listitem>

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

	<para><?xxe-sn 2f0cduzin5j -wunr7fl0rw7r?>The compiler allows
	Transcend to add hidden parameters every time specific functions are
	invoked. This is implemented to support the <link
	xlink:href="/d/concepts/context/"><?xxe-sn 2f0cduzin5j -wunr7fl0rw7q?>Context</link>
	concept.</para>
	</listitem>

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

	<para><?xxe-sn 2f0cduzin5j -wunr7fl0rw7o?>Diagnostics. Transcend is
	able to validate different aspects of a program and print diagnostic
	messages to signal found inconsistencies.</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 2f0cduzin5j -wunr7fl0rw7n?>As an example, suppose we want
	to control functions visibility and want to separate the <code><?xxe-sn 2f60onvmups 2?>visibility(private)</code>
	functions from the rest of a program:</para>

	<programlisting xml:id="Diagnostics1"><?xxe-sn 2f0cduzin5j -wunr7fl0rw7m?>name="tests/transcend.cpp: Transcend.Doc_Diagnostics1"
	sum = function(a:: int, b:: int) :: int; visibility(private)
	{
	a + b
	}

	calculate = function(a:: int, b:: int):: int; visibility(pub_interface)
	{
	sum(a, b)
	}

	test = function(a:: int, b:: int) :: int; entry
	{
	sum(a, b) // we may not invoke this directly
	}</programlisting>

	<para><?xxe-sn 2f0cduzin5j -wunr7fl0rw7l?>Transcend converts the code
	above to logic facts as follows(the relevant part is shown):</para>

	<programlisting><?xxe-sn 2f0cduzin5j -wunr7fl0rw7j?>function(sum)
	function(calculate)
	function(test)

	bind_func(sum,visibility(private))
	bind_func(calculate,visibility(pub_interface))
	bind_func(test,entry)

	cfa_parent(0,function(sum))
	cfa_parent(1,function(calculate))
	cfa_parent(2,function(test))

	cfa_call(1,sum)
	cfa_call(2,calculate)</programlisting>

	<para><?xxe-sn 2f0cduzin5j -wunr7fl0rw7i?>At this point all the
	annotations are completely unknown to the compiler. Next, we need to write
	rules to check that the <code><?xxe-sn 2f0cduzin5j -wunr7fl0rw7h?>visibility(private)</code>
	functions are called either by another <code><?xxe-sn 2f0cduzin5j -wunr7fl0rw7g?>visibility(private)</code>
	ones or by the <code><?xxe-sn 2f0cduzin5j -wunr7fl0rw7f?>visibility(pub_interface)</code>
	functions which are intended to act as a contact point, the only allowed
	gate between the private part and the rest of a program:</para>

	<programlisting xml:id="Diagnostics1_Rules"><?xxe-sn 2f60onvmups 1?>name="tests/transcend.cpp: Transcend.Doc_Diagnostics1"
	% Define which functiones are allowed to invoke private ones
	allowed(
	visibility(private);
	visibility(pub_interface)
	).

	% Check every invocation for violations:
	warning("Visibility violation", FuncFrom, FuncTo):-
	cfa_call(ScopeFrom, FuncTo);
	bind_func(FuncTo, visibility(private));
	scope_func_dict(ScopeFrom, FuncFrom);
	{ bind_func(FuncFrom, Visibility): allowed(Visibility) } 0.</programlisting>

	<para><?xxe-sn 2f60onvmups 3?>Given the rules Transcend goes through all
	the invocations to check are there any possible visibility violations. For
	this example Transcend generates a diagnostic message: <code><?xxe-sn 2f60onvmups 4?>warning("Visibility violation",test,sum)</code>.</para>

	<para><?xxe-sn 2f60onvmups 5?>This way it is possible to validate and
	guide compilation process by analysing program properties employing
	provided processing rules.</para>
	</section>

	<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 to be processed by the compiler along with a
	source code proper with an end goal being to affect a compilation process.
	Annotations are special expressions in the following form:</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="#expressions"><?xxe-sn 2ajela3ur5s 8m?>Expressions</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="/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="/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?>Expressions</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>
	The 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 annotations attached to the expression. Annotations are
	delimited by semicolon.</para>
	</listitem>
	</itemizedlist>

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

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

	x+y
	}</programlisting>

	<para><?xxe-sn 2ezs03nkiyo 9?>For readability's sake compound
	statements(e.g. <link xlink:href="/d/syntax/#loops"><?xxe-sn 2ezs03nkiyo a?>loops</link>)
	have slightly different syntax for annotations. See particular
	statement's syntax for details.</para>

	<note>
	<?xxe-sn 2ezs03nkiyo 2?>

	<para><?xxe-sn 2ezs03nkiyo 3?>A current limitation is that
	expression's annotations are always preceded by a type, hence to
	annotate nested expressions it is necessary to duplicate the
	expression's type.</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>
	A list of annotations delimited by semicolon</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 2ajela3ur5s 9h?>Code block annotations are called
	<emphasis><?xxe-sn 2ajela3ur5s 9i?>context</emphasis>. The keyword
	<code><?xxe-sn 2ajela3ur5s 9j?>context</code> is reserved to declare
	annotations within an enclosing code block.</para>

	<para><?xxe-sn 2ajela3ur5s 9k?>An 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?>Despite of "annotations do not have any
	predefined meaning" being a rule of thumb, still there are deviations in
	Xreate; few annotation that have special meaning are:</para>

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

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

	<colspec colwidth="91*"><?xxe-sn 2ezs03nkiyo b?></colspec>

	<colspec colwidth="909*"><?xxe-sn 2ezs03nkiyo c?></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 the entry point of a
	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 the fixed point of
	loops. See <link xlink:href="/d/syntax/#loops"><?xxe-sn 2ajela3ur5s a3?>Loops</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
	additional pieces of information and can occur in a 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 and expressions, statements, code blocks, functions,
	modules or even a whole program.</para>

	<para><?xxe-sn 2ajela3ur5s a7?>Annotations are <emphasis><?xxe-sn 2ezs03nkiyo d?>explicit
	facts </emphasis>about a source code provided by a code writer in an
	explicit form. Beside annotations, there are other sources of information,
	in other words, <emphasis><?xxe-sn 2ezs03nkiyo f?>implicit
	facts</emphasis> that are automatically inferred by various analysis
	phases to express useful insights regarding an analysed code. Such pieces
	aren't exposed directly to a developer but accessed and used internally at
	the 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</entry>

	<entry><?xxe-sn 2ajela3ur5s ag?>Annotations provided by a code
	writer 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 provide
	information implicitly inferred from a 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 a
	hardware and/or an environment where compilation takes place or
	where a program is supposed to work. There are many supervision
	layers possible, from custom compiler's mode, to OS- or computer-
	or even network-wide levels. In other words, supervision covers
	local or client supplied annotations, e.g. prohibits web cam
	usage, or external network resources access.</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 reflects 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 a 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. A
	developer is free to define and use custom annotations to express
	desired properties without prior changes to the compiler.</para>
	</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 only an input for a reasoning procedure that ultimately decides
	how exactly to 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 enabling annotations to complement each other. The compiler
	blends in annotations originated from various sources seamlessly 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 can be used not only to
	express properties of a program itself but also properties of a local
	environment(OS, computer, local network) where the program is supposed
	to run. Thus, in fact, the compiler operates by information that is
	usually inaccessible during software development and can't be reflected
	in a program code otherwise. In essence, it is <emphasis><?xxe-sn 2ezs03nkiyo g?>postcompilation</emphasis>
	- a process of adjustments 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 of interaction between
	components. For example, let us focus on a client-service model. A
	service works the same regardless of a particular client in order to be
	compatible with as wide set of different clients as possible. However
	clients may use only small subset of service functionality or use it in
	a specific and predictable order. Generally speaking, the service in
	case of having additional information about a particular client is able
	to serve requests more efficiently in many situations.</para>

	<para><?xxe-sn 2ajela3ur5s bg?>It can be conceptualized as a
	<emphasis><?xxe-sn 2ajela3ur5s bh?>feedback</emphasis> from a client.
	Annotations is a 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 a program grows and goes through
	multiple reworks and rewrites many initial assumptions about the code
	and relation between different parts invalidated. Some implementation
	details and approaches became outdated and code quality deteriorates. A
	dIfferent picture is if the code uses annotations to express important
	properties. Any changes in an underlying code lead to a restarting of a
	reasoning procedure which adjust implementation decisions to be as
	optimal in a changed environment as before.</para>
	</section>
	</section>
	</chapter>
	diff --git a/documentation/exploitation.xml b/documentation/exploitation.xml
	index 299281a..784c0f9 100644
	--- a/documentation/exploitation.xml
	+++ b/documentation/exploitation.xml
	@@ -1,490 +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 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="/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>
	+ another topic that deals with I/O, exploitation approaches the subject from
	+ a different angle — it is concerned with <emphasis><?xxe-sn 26yv439af40 x?>order
	+ of operations</emphasis>, a sequence in which different clients jointly use
	+ the same resource, and it deals with corresponding difficulties, e.g.
	+ ensures proper initialization of a resource before its 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
	+ <para><?xxe-sn 29je46abuev -wunr7fl0rw8l?>Annotates a 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>
	+ is expected to do nothing as initialization is either not 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"
	+ side effects has received considerable traction. Indeed, side effects are
	+ something that is hard to take into account, and thus programs that have
	+ side effects are inherently unsafe, so best coding practices rightfully
	+ suggest to isolate the code that produces side effects as much as
	+ possible. It is so called pure functional languages whose philosophy goes
	+ even further and frames side effects as something opposite of "pure" and
	+ built around effectless computations, to the point that some languages'
	+ design itself includes side effects producing constructs, such as I/O,
	+ describing them as an afterthought, as something almost
	+ unnecessary.</para>
	+
	+ <remark><?xxe-sn 2eplydoeos0 pu35zrt1aby9?>Я тут взял на себя смелость
	+ подредактировать последнее предложение, посмотри внимательно - все ли я
	+ правильно понял</remark>
	+
	+ <para><?xxe-sn 26yv439af40 c?>However, in reality the opposite is true, as
	+ most applications' sole responsibility is to communicate with the "outside
	+ world", reacting to the external events and changing the "world's 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>
	+ <emphasis><?xxe-sn 26yv439af40 d?>only</emphasis> important effects
	+ produced by a program, and they surely deserve a first class support from
	+ a programming language and justify the efforts to develop an approach to
	+ alleviate the 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
	+ <para><?xxe-sn 26yv439af40 12?>One complexity with taking side effects
	+ into account is that the final result depends on an <emphasis><?xxe-sn 28ivhnywem8 1?>exact
	+ order of operations</emphasis>. For many techniques, this harshly impacts
	+ both performance and safety, e.g. caching or 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
	+ <remark><?xxe-sn 2fs606w84j4 pu35zrt1aby9?>Мне не очень нравится фраза
	+ "deal with possibly undetermined beforehand order of execution". Выглядит
	+ очень громоздко. Может, лучше сказать "or are connected with such an order
	+ of execution that was not determined beforehand".</remark>
	+
	+ <para><?xxe-sn 28ivhnywem8 2?>In this chapter, it is assumed that final
	+ effects of execution are 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
	+ those that deal with an exploited resource. Other (unannotated) code
	+ blocks are assumed to not produce exploitation effects, so they are
	+ excluded from consideration. Thus reasoning about effects is reduced to
	+ considering all possible exploitation paths, checking if they meet certain
	+ requirements that define valid exploitation, and making corrections if
	+ needed and possible.</para>
	+
	+ <para><?xxe-sn 26yv439af40 13?>The result of the reasoning is called
	+ <emphasis><?xxe-sn 26yv439af40 14?>exploitation plan</emphasis> — a
	+ specification that defines the 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>
	+ <para><?xxe-sn 26yv439af40 18?>Annotations are used to express certain
	+ aspects of side effects to enable further reasoning. They indicate the
	+ code blocks that deal with a resource as well as provide additional
	+ information about how exactly it is exploited, e.g. using,
	+ initializing or deinitializing the 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>
	+ <para><?xxe-sn 28ivhnywem8 5?>Existing code paths extracted during
	+ source code processing and coupled with relevant annotations are
	+ enough to construct all possible exploitation paths and analyze them.
	+ The analysis determines possible (<emphasis><?xxe-sn 295bzzou9kw 3?>weak</emphasis>)
	+ paths that can either occur or not occur during particular execution,
	+ as well as certain paths (<emphasis><?xxe-sn 295bzzou9kw 4?>strong</emphasis>)
	+ that occur under any conditions. Also it checks if an exploitation
	+ path is valid against certain exploitation rules, e.g. initialization
	+ always occurs before the actual usage, and if it is possible to
	+ correct the 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>
	+ <para><?xxe-sn 28ivhnywem8 7?>The reasoning's result is an
	+ exploitation plan that dictates the order and strategy of exploitation
	+ presented in the form of an 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>
	+ <para><?xxe-sn 26yv439af40 1a?>Exploitation-related side effects are
	+ viewed as a set of additional restrictions over the operations' order.
	+ Only the subset of possible reorders is still valid w.r.t. side
	+ effects. Transcend's task is to achieve a refined set of valid orders.
	+ Thus techniques that rely on reordering enjoy an 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>
	+ <para><?xxe-sn 26yv439af40 1e?>Safety. Validates the existing
	+ exploitation plan, or determines if it is possible at all to safely
	+ exploit a given resource. Compiler signals an 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>
	+ program. Sometimes refactoring or other code changes break those
	+ dependencies, which inevitably results in regressions. Exploitation
	+ catches this sort of regressions and automatically regenerates the
	+ exploitation plan suited for 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
	+ for example, by preventing resource initialization in several places
	+ if it can be done safely in just one place, 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
	+ <para><?xxe-sn 27ay8x1a5mo 3?>When it comes to reasoning about the order
	+ of execution and possible code paths, the 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
	+ <para><?xxe-sn 27ay8x1a5mo 6?>Unlike the usual function-bound domination
	+ analysis, when a separate domination tree is produced for each function
	+ defined in a program, Exploitation requires a program-bound analysis, that
	+ is taking into account the control flow across all functions in a program.
	+ It is a computationally intensive task to perform an 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>
	+ takes into account the code blocks that deal with or, in other words,
	+ exploit external resources. Thus there is no necessity to build a 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>
	+ against some predefined constraints. Depending on complexity of the
	+ constraints, i.e. the number of different exploitation events that are
	+ sought for in each path, reasoning goals are 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>
	+ Meaning that all paths are checked to determine if there is
	+ exploitation at all or not, and if there is 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>
	+ Deals with the situations where it is enough to check only two
	+ different exploitation events occurring in a required order. It can be
	+ useful for example, to check whether all resource uses occur after it
	+ is initialized.</para>
	+
	+ <remark><?xxe-sn 2fsua1xc9o0 pu35zrt1aby9?>"to check only two
	+ different exploitation events occur in a required order" - нужно
	+ уточнить смысл фразы. "Уточнить только два события, осуществляющиеся в
	+ требуемом порядке", или "уточнить, осуществляются ли два этих
	+ события"? Я использовал герундий (occur - occurring), как более
	+ нейтральный вариант.</remark>
	</listitem>

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

	<para><?xxe-sn 28j5661y0mv -wunr7fl0rw8n?>Higher Order Exploitation.
	- Expresses constraints involving several(more than two) 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>
	+ Exploitation</emphasis> is an important instance of the zero order
	+ constraint. It is a useful mechanism for the developer to annotate a
	+ function or part of a program as effect free in terms of exploitation.
	+ Thus, effectless, clean or pure code can be clearly separated from the
	+ effectful part, and compiler raises a compilation error in case of
	+ accidental mixing or using "wrong" type of code in a 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
	+ <para><?xxe-sn 26yv439af40 w?>One important problem related to
	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>
	+ initialized before its first usage and, additionally, that it is not
	+ initialized more than once during the exploitation session. This is the
	+ instance of first order exploitation since in a validation mode it is
	+ enough to check the exploitation plan to ensure that every resource usage
	+ was 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>
	+ <para><?xxe-sn 28jw0wb6fpc 2?>For the 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>
	+ <para><?xxe-sn 28jw0wb6fpc 5?>The central idea of the algorithm is to
	+ consider candidates for initialization only among those code blocks
	+ that <emphasis><?xxe-sn 295bzzou9kw 5?>dominate</emphasis> a given
	+ usage site. Obviously, initialization in the 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
	+ for actual initialization in such way that they cover all the 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>
	+ <para><?xxe-sn 295bzzou9kw 9?>For the code blocks chosen for
	+ initialization, the specialization <code><?xxe-sn 295bzzou9kw a?>exploitation(init)</code>
	+ is set, while for the rest of the code blocks the 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>
	+ <para><?xxe-sn 28h47d43thc 1?>Please take a 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>
	+ that executes sequentially the following commands: open a file (scopes #1
	+ and #2), write some text (scope #3), and finally, close the file (scope
	+ #4). It represents a 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
	+ 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
	+ initialize a 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
	+ the 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.
	+ the resource before usage. Next task for exploitation is to choose the
	+ correct exploitation plan, i.e. to assign strategies for all possible
	+ initialization places in the effort to initialize the 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
	+ to actually initialize the file. The other one is automatically marked
	+ with <code><?xxe-sn 28h47d43thc g?>exploitation(none)</code> to invoke a
	different specialization of <code><?xxe-sn 28h47d43thc h?>openFile</code>
	- that does nothing since the file is already initialized.</para>
	+ that does nothing since the file was already initialized.</para>
	</section>
	</chapter>
	<?xxe-revisions
	+#17 2019-05-28T07:25:43Z pgess
	+#16 2019-05-25T22:11:48Z Администратор
	+1sPEAAABgZElADiBkQEAAxkVbGF1c656IwwTBkMEpSMNU4xfAQFTCt8TBWPUaQDJOJcPkDaITNNQ
	+mC2BH5wyiTqLYQ==
	+
	+#15 2019-05-25T19:18:44Z Администратор
	+1sPEAAABgZEBAIQhgYp9ABSCNIFQbGxpYXJlbW9vbiBlZSwnbkNMbixzxRMTGkMEEwVTDRMEYwtj
	+D1MEAQJTE0ODMjMEUyszDAEBQwQTB0NZMx0BAUOBZN1TRjMJAQIzgV9DBFMIEwZTE1MGUxgzgXoT
	+BEMZY2MzBwEBMxkTE1M3MyxDbVMaEwVjUEODChMGUw4zMuNDIlMEY4FtQwlTBmMFQxcBASMKQ4FH
	+YwRjDPdDN1MHIwVTB2NxEwxTKxMUY1xjgXgzGkMVUxZjTzM6Qw5TFWNQAQETCDOBSEMQU1tjCyME
	+MxxDBGMLQx5TVmM2M4FCQ4EkAQFTVWMOYztDLyMIU4FhEwQzClNskwxjGUNSUw0zgRQBATOLEMdD
	+FWMKAQEzFZMGQwRjHDMaQ4ECEw1TgiaDDxMHUwwzggaDBzOBUVM/EwhzEWNfU4FbEwZjZRMKkw9j
	+H0M1YwRDMgDFF65Drg2XXJpgl1SEc5NbGxaqHoM1MokunU4XXRyZYoFyjzRTgh2MEK9lgXODbBQc
	+uCuBfBuCGG2aES85L3HFMR9SojSDEhKDYTiPcSqNfZo+iByCCCQqp2qBTZ0sE6s6kFepK0+OWFKN
	+NoVGXYF8HxkYUD4PF4c5W7Y4gVWDFZ0xcYdsIA8iWjqBRoEphVZpPZtbO5JTgWEOQ3weWBCBI4tU
	+ix4WDqocBR0cgYIxgRCAiWsLgkq5ghGBVbxnxFxjrnSBZYdaU5Z6gR+SBzo=
	+#14 2019-05-06T11:44:19Z Администратор
	+1sPEAAABgYp+AIMjgYc+ABCBX4ErLG9kUixudHdoYXRSaWZpdXObIRMZQwQTikxDBEMlUwxDRRMJ
	+UwZDDGMEMzBjBBMREwUzBwEBM4FGExBDLFMEYx5TBhMIQ4IlMwYBATOBAwEBMwdTODNXAQFDZ1MF
	+UxYzgmRDBUNDEwozCTMIY10jBDMKYw4jClMWExRDC1M1YwRDBWMgAQFTI0MEY0VDCEMUY0UTBjMH
	+QwcTCzMJYwxTCGMFU0NjB9O7AQRDERMEMxFDEHMMIwhjEBMEYwQzBRMHYwxTBkMRQwhjZAEBMzhD
	+I1MFEwjgUwYTBFOBfmMKM0AjEFMHM1emxxMGQ0RDyAkAnT6ZCJtClB2IVp1SLIgwqmWEZJwBnwys
	+G6cpiTo1CoN4hC2jQC+XDI40MIVhgi6CKIELOVy/NW4alVCCbI82oSKZRmS3ZoEwb7gbqTiNC5ll
	+kH+dB4xLPSSdHyiVT1EVrXNSBoUPpB+IPIVRnwqEPiKZW4NAV5JTiyQqBpERgh2tdJ44jjaJawsk
	+iGUaDGk8qEC0GogBN4c9DZ0JggiWb1ULqSK8V442aUc=
	#13 2019-03-07T18:19:21Z pgess
	+1sPEAAABgYc+AIFSgYUHABBwS2RvY3V0YWNrbGVuJ3ZkaXNzhw4TCdAjBVMEQwoBBkMHQxhjOFMY
	+My9TQWNDIxgzB1OFMmOIBAECM4IGAQEjBEMzYwVjKUNBMwVTFhMFMx1TM2MEY333IwYjBgECQyVD
	+alM9Y0gzPkM6UwhjgQojBDMIMwczBhMOQzxTFGMVM+J7AIcLpmeqBZBgCpZOGhyIdE0xQqtdYAuF
	+NIgOnSOCCoITOSquF0SSUxchhnU4hwq+eZ0lgQEmeoJHS0JACqE/rG2sJo1jo0MQQBcZ
	#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 8c227b4..38c577d 100644
	--- a/documentation/index.xml
	+++ b/documentation/index.xml
	@@ -1,425 +1,434 @@
	<?xml version="1.0" encoding="UTF-8"?>
	<chapter version="5.1" xmlns="http://docbook.org/ns/docbook"
	xmlns:xlink="http://www.w3.org/1999/xlink"
	xmlns:xila="http://www.w3.org/2001/XInclude/local-attributes"
	xmlns:xi="http://www.w3.org/2001/XInclude"
	xmlns:trans="http://docbook.org/ns/transclusion"
	xmlns:svg="http://www.w3.org/2000/svg"
	xmlns:m="http://www.w3.org/1998/Math/MathML"
	xmlns:html="http://www.w3.org/1999/xhtml"
	xmlns:db="http://docbook.org/ns/docbook">
	<?xxe-sn 2b06cb2u4g0 1?>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	<programlisting><?xxe-sn 2da0r0b6680 9?>logger = createFileLogger("/some/file"):: Logger.
	...

	write(logger, "First log entry").
	...

	write(logger, "Last log entry").</programlisting>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	<para><?xxe-sn 2fchdmt7vgg k?>Thus we can safely change and adapt our
	program knowing that clients always receive web page's content in the
	correct order by automatically employing the most efficient content
	delivery strategy depending on particular circumstances.</para>
	</section>

	<section>
	<?xxe-sn 2fs1xxghz93 -wunr7fl0rw8u?>

	<title><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8t?>Differences from other
	languages</title>

	<para><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8s?>it is convenient to talk about
	<emphasis><?xxe-sn 2fs1xxghz93 -wunr7fl0rw88?>intentions</emphasis> in
	order to outline a vast landscape of programming languages and point out
	- the place of Xreate on it, i.e. to compare languages on a basis do they
	+ the place of Xreate on it, i.e. to compare languages depending on do they
	allow to express a developer's intentions along with raw code that can be
	- used on many occasions, e.g. to validate code's correctness. Traditionally
	- type system is used to declare intentions. At closer look, types in
	- (imperative) statically typed languages contain information as
	- follows:</para>
	+ used on many occasions, e.g. to validate the code's correctness.
	+ Traditionally type system is used to declare intentions. At closer look,
	+ types in (imperative) statically typed languages contain inseparable
	+ combination of the following:</para>

	<itemizedlist>
	<?xxe-sn 2fs1xxghz93 -wunr7fl0rw8q?>

	<listitem>
	<?xxe-sn 2fs1xxghz93 -wunr7fl0rw8p?>

	<para><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8o?>Intentions, such as "that
	- variable is a string". </para>
	+ variable is a string".</para>
	</listitem>

	<listitem>
	<?xxe-sn 2fs1xxghz93 -wunr7fl0rw8n?>

	- <para><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8m?>Usage patterns. A new code
	+ <para><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8m?>Usage patterns: a new code
	should play nicely with the rest of a program, e.g. if a program works
	- with Unicode, a new string variable should be also of Unicode
	- type.</para>
	+ with unicode, a new string variable should be also of unicode family
	+ type(even if this is not necessary for a given part of code)</para>
	</listitem>

	<listitem>
	<?xxe-sn 2fs1xxghz93 -wunr7fl0rw8l?>

	<para><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8k?>Platform constraints, e.g.
	if a platform supports wide strings natively, a new string variable
	should also be a wide string.</para>
	</listitem>
	</itemizedlist>

	<para><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8j?>In this regard, in general,
	statically typed languages are <emphasis><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8i?>overconstrained</emphasis>,
	- they require developers to provide more information then they intend to.
	- This generally hinders code reuse and adaptation; to work on a new
	- platform, code requires porting: a process of re-expressing underlying
	- intentions once again with the new platform's constraints. </para>
	+ they require developers to provide more information than they intend to.
	+ This usually hinders code reuse and adaptation; to work on a new platform,
	+ software requires porting: a process of re-expressing underlying
	+ intentions once again with the new platform's constraints.</para>

	<para><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8h?>On the other side, dynamically
	- typed languages in this regard are <emphasis><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8g?>underconstrained</emphasis>,
	+ typed languages are <emphasis><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8g?>underconstrained</emphasis>,
	since they do not allow to express all desirable intentions. This leads to
	- a disastrous inefficiency and code fragility because any errors can be
	- caught only at runtime. </para>
	+ disastrous inefficiency and code fragility because any errors can be
	+ caught only at runtime.</para>

	- <para><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8f?>OOP languages are hugely
	- successful among other reasons because they provide <emphasis><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8e?>classes</emphasis>
	- to more finely express intentions, e.g. <code><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8d?>String</code>,
	+ <para><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8f?>As an example, OOP languages are
	+ hugely successful among other reasons because they provide
	+ <emphasis><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8e?>classes</emphasis> to more
	+ finely express intentions, e.g. <code><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8d?>String</code>,
	<code><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8c?>UnicodeString</code>,
	<code><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8b?>Utf8String</code> with exact
	behaviour being hidden in implementation details.</para>

	- <para><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8a?>Xreate in its turn offers
	- annotations for developers to express intentions, e.g. <code><?xxe-sn 2fs1xxghz93 -wunr7fl0rw87?>string;i_dont_need(cow)</code>
	- (copy-on-write implementation). Annotations alone is not enough to fully
	- determine necessary types thus the compiler finishes them by looking at
	- usage patterns along with platform properties in order to infer most
	- efficient implementations.</para>
	-
	- <para><?xxe-sn 2fs1xxghz93 -wunr7fl0rw86?>Also there is an area beyond
	- type systems capabilities, since types are designed to express intentions
	- only about data flow. However as shown in the previous example it is also
	- useful to express intentions about program structure properties, such as
	- operations order. </para>
	+ <para><?xxe-sn 2fs1xxghz93 -wunr7fl0rw8a?>Xreate in its turn is based on
	+ the idea to allow developers express as much or as little intentions as
	+ they want to. This is a way to reach one of the the language's goals to
	+ facilitate writing of easily reusable and adaptable software. On a syntax
	+ level, annotations are used to express intentions, e.g. <code><?xxe-sn 2fs1xxghz93 -wunr7fl0rw87?>string;i_dont_need(utf8)</code>(note
	+ the modality, annotations can express boundaries, preferences, etc. ).
	+ </para>
	+
	+ <para><?xxe-sn 2fxwo1r89a8 1?>This approach obviously leads to problems
	+ with software's performance and efficiency. For most high level languages,
	+ compilers rely on defaults to fill in unspecified by the developer gaps in
	+ the exact implementation details. Usually languages provide standard,
	+ default data structures the developer have no control over. However Xreate
	+ follows another approach: to resolve this contradiction, the compiler
	+ determines necessary implementation details not only depending on
	+ annotations, but also by looking at usage patterns along with platform
	+ properties trying to infer most efficient implementations in any given
	+ circumstances.</para>
	</section>
	</chapter>

No OneTemporaryActions

File Metadata

View Options

Event Timeline

No OneTemporary
Actions