No OneTemporary
Actions

Subscribers

None

File Metadata

Created: Sun, Feb 15, 5:11 PM

View Options

	diff --git a/documentation/Concepts/context.xml b/documentation/Concepts/context.xml
	index 16a26ec..8d1cd0a 100644
	--- a/documentation/Concepts/context.xml
	+++ b/documentation/Concepts/context.xml
	@@ -1,304 +1,312 @@
	<?xml version="1.0" encoding="UTF-8"?>
	<chapter version="5.1" xmlns="http://docbook.org/ns/docbook"
	xmlns:xlink="http://www.w3.org/1999/xlink"
	xmlns:xila="http://www.w3.org/2001/XInclude/local-attributes"
	xmlns:xi="http://www.w3.org/2001/XInclude"
	xmlns:trans="http://docbook.org/ns/transclusion"
	xmlns:svg="http://www.w3.org/2000/svg"
	xmlns:m="http://www.w3.org/1998/Math/MathML"
	xmlns:html="http://www.w3.org/1999/xhtml"
	xmlns:db="http://docbook.org/ns/docbook">
	<?xxe-sn 2ahi4rjnvuo 1?>

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

	<para><?xxe-sn 2ahi4rjnvuo 3?>Computer program, its internal states and
	transitions between them can be looked at from two different points of view:
	control flow and data flow. In order to express and employ control flow
	related program's properties Xreate supports mechanism called
	<emphasis><?xxe-sn 2axopn9e3uo 1?>context</emphasis> — ability to assign
	transcend data to a code blocks in a way that related blocks in the CFG have
	- related contexts. </para>
	+ related contexts.</para>

	<para><?xxe-sn 2ahi4rjnvuo 5?>Code block's context is exhaustingly defined
	as follows:</para>

	<itemizedlist>
	<?xxe-sn 2ahi4rjnvuo 6?>

	<listitem>
	<?xxe-sn 2ahi4rjnvuo 7?>

	<para><?xxe-sn 2ahi4rjnvuo 8?>Block's place within the code in terms of
	hierarchy of all its respective parents.</para>
	</listitem>

	<listitem>
	<?xxe-sn 2ahi4rjnvuo 9?>

	<para><?xxe-sn 2ahi4rjnvuo a?>Historical data determined by previous
	visited code blocks in terms of "caller-callee" relation graph.</para>
	</listitem>
	</itemizedlist>

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

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

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

	<programlisting xml:id="Examples_1"><?xxe-sn 2ahi4rjnvuo f?>//someStringFn = function:: string {...}

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

	<para><?xxe-sn 2ahi4rjnvuo g?>In this example the annotation
	<code><?xxe-sn 2ahi4rjnvuo h?>env(utf8)</code> conveys some information
	about the block thus distinguishing it from the others, which allows to
	apply specific compilation rules for this block. Suppose <code><?xxe-sn 2ahi4rjnvuo i?>someStringFn</code>
	has different specializations for different environments. Now it's
	possible to invoke specialization tailored for UTF8 environment. In this
	case context can be viewed as a <emphasis><?xxe-sn 2axopn9e3uo 2?>suggestion</emphasis>
	- to pick up appropriate specialization. </para>
	+ to pick up appropriate specialization.</para>

	<para><?xxe-sn 2ahi4rjnvuo j?>Also there is possibility to define expected
	context properties:</para>

	<programlisting xml:id="Examples_2"><?xxe-sn 2ahi4rjnvuo k?>name - "...."
	guard:: safe
	{
	crucialOperation = function:: int
	{0}
	}

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

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

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

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

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

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

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

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

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

	<para><?xxe-sn 2axopn9e3uo 9?>Parent context. Block's context inherits
	context of its parent reflecting block's place within a
	program.</para>
	</listitem>

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

	<para><?xxe-sn 2axopn9e3uo b?>Client context. Blocks context also
	includes caller's context reflecting control flow. It allows taking
	into account in which context a given code is used.</para>
	</listitem>
	</itemizedlist>

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

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

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

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

	<para><?xxe-sn 2ahi4rjnvuo x?>demonstrates context propagation to a nested
	block which is exhibited by availability of a <code><?xxe-sn 2ahi4rjnvuo z?>env(safe)</code>
	annotation in the context of the nested block <code><?xxe-sn 2ahi4rjnvuo 10?>blockB</code>
	despite being defined in the <code><?xxe-sn 2ahi4rjnvuo 11?>blockA</code>.</para>

	<para><?xxe-sn 2ahi4rjnvuo 12?>Another case is propagation from caller to
	a callee. It means context propagates through "caller/callee" relation —
	callee inherits caller context. The example below demonstrates
	this:</para>

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

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

	test = function:: int; entry
	{
	context:: units(mm).
	calculate(10)
	} </programlisting>

	<para><?xxe-sn 2ahi4rjnvuo 15?>Suppose <code><?xxe-sn 2ahi4rjnvuo 16?>calculate()</code>works
	with values measured in different units. It normalizes each value by
	invoking <code><?xxe-sn 2ahi4rjnvuo 17?>toSI()</code> conversion. One
	approach is to keep unit information for each variable independently. But
	if we know that entire program or a part of it works only with specific
	unit we can register it in a context, <code><?xxe-sn 2ahi4rjnvuo 18?>units(mm)</code>in
	this example, letting functions <code><?xxe-sn 2ahi4rjnvuo 19?>calculate()</code>
	and its callees inherit context allowing compiler to generate code
	tailored for specific units only.</para>
	</section>

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

	- <title><?xxe-sn 2ahi4rjnvuo 1n?>Latex (Late Context)</title>
	+ <title condition="incomplete"><?xxe-sn 2ahi4rjnvuo 1n?>Latex (Late
	+ Context)</title>
	+
	+ <note>
	+ <?xxe-sn 2cpm8zia70g 3?>
	+
	+ <para><?xxe-sn 2cpm8zia70g 4?>This section is still incomplete. It will
	+ be reworked soon.</para>
	+ </note>

	<para><?xxe-sn 2ahi4rjnvuo 1o?>Static(compile-time) context reasoning is
	<emphasis><?xxe-sn 2ahi4rjnvuo 1p?>weak</emphasis> since it's able to
	infer only partial context, consisting of properties that are true for all
	possible paths leading in a CFG to a given block. Beyond that are entries
	that depend on exact path in CFG. Such uncertainty is possible to resolve
	during runtime once it's known which path exactly is chosen.</para>

	<para><?xxe-sn 2ahi4rjnvuo 1q?>To solve this problem <emphasis><?xxe-sn 2axopn9e3uo 11?>late
	context</emphasis> is introduced - embedding into compiled code certain
	instructions to gathered data on relevant occasion at runtime to determine
	exact or <emphasis><?xxe-sn 2axopn9e3uo 12?>strong</emphasis>,
	context.</para>

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

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

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

	<para><?xxe-sn 2ahi4rjnvuo 1v?>Set of all possible context facts for
	the given block is computed during compile time. Each such fact is
	- associated with code paths it holds for. </para>
	+ associated with code paths it holds for.</para>
	</listitem>

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

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

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

	<para><?xxe-sn 2ahi4rjnvuo 1z?>Late parameter is used as guard for
	late transcend facts context consists of.</para>
	</listitem>
	</itemizedlist>

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

	compute = function:: int
	{ 0 }

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

	compute()
	}

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

	compute()
	}

	test = function(cmnd:: int):: int; entry {
	context:: arithmetic(iee754).

	if (cmnd > 0)::int {computePrecisely()} else {computeFast()}
	}</programlisting>

	<para><?xxe-sn 2ahi4rjnvuo 22?>Static scope</para>

	<para><?xxe-sn 2ahi4rjnvuo 23?></para>

	<programlisting><?xxe-sn 2ahi4rjnvuo 24?>name = "..."
	import raw ("core/control-context.lp")
	case context:: computation(fast) {
	compute = function:: num {
	0
	}
	}

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

	executeComputation= function:: num {
	compute()
	}

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

	} else {
	context:: computation(precise).
	executeComputation()
	}
	}</programlisting>

	<para><?xxe-sn 2ahi4rjnvuo 25?>To sum it up, context consists of two
	complements parts: on the one hand <emphasis><?xxe-sn 2axopn9e3uo 15?>static(early)
	context</emphasis>, that denotes compile time inference's result and on
	the other hand, <emphasis><?xxe-sn 2axopn9e3uo 16?>late(dynamic)
	context</emphasis> denotes annotations decided upon at runtime.</para>
	</section>
	</chapter>
	diff --git a/documentation/index.xml b/documentation/index.xml
	index 5033a93..4f76967 100644
	--- a/documentation/index.xml
	+++ b/documentation/index.xml
	@@ -1,216 +1,216 @@
	<?xml version="1.0" encoding="UTF-8"?>
	<chapter version="5.1" xmlns="http://docbook.org/ns/docbook"
	xmlns:xlink="http://www.w3.org/1999/xlink"
	xmlns:xila="http://www.w3.org/2001/XInclude/local-attributes"
	xmlns:xi="http://www.w3.org/2001/XInclude"
	xmlns:trans="http://docbook.org/ns/transclusion"
	xmlns:svg="http://www.w3.org/2000/svg"
	xmlns:m="http://www.w3.org/1998/Math/MathML"
	xmlns:html="http://www.w3.org/1999/xhtml"
	xmlns:db="http://docbook.org/ns/docbook">
	<?xxe-sn 2b06cb2u4g0 1?>

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

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

	<para><?xxe-sn 2b06cb2u4g0 8?>Here "high level" has very specific meaning,
	implying an ability to easily write, read, as well as adapt software to a
	constantly changing environment or business goals. In this respect, any
	software product can be evaluated on the basis of the three dimensions:
	efficiency, safety, and adaptability. Unfortunately, those properties are
	proved to be largely contradictory, for it is manageable to write either
	efficient (yet unsafe) or safe (yet impractical) code, but not both. Thus,
	the ultimate goal of the language is to allow developers to produce code
	that would have all these properties at the same time. Xreate's design
	principles allow to adopt any programming technique as long as it does not
	improve one dimension at the expense of another.</para>

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

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

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

	<para><?xxe-sn 2b06cb2u4g0 g?><link xlink:href="/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 level alone is not enough to constitute a full-fledged language
	since code requires various non-executable metadata to express
	developer's intents, check correctness, validity and perform other types
	of analyses. In Xreate everything of this sort belongs to a layer called
	<emphasis><?xxe-sn 2b06cb2u4g0 s?>Transcend</emphasis>. Transcend due to
	its declarative nature is appropriate to do management-type work — it
	analyzes, oversees and controls brute by guiding compilation process.
	Everything on this level — logic or transcend facts and rules — is
	gathered and sent to an external logic solver to make solutions that are
	brought back in order to guide compilation.</para>
	</listitem>

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

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

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

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

	<para xlink:href="w/virtualization/"><?xxe-sn 2b3f3osfk74 g?>Most severe and
	hard to resolve problems in software development stem from interaction of
	different components on different levels. Each individual component often is
	thoroughly tested and works reliably. But combining them when building
	end-user software for which purpose complex interaction and extensive IO is
	enabled usually leads to a range of runtime errors, security vulnerabilities
	and performance degradation.</para>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

No OneTemporaryActions

File Metadata

View Options

Event Timeline

No OneTemporary
Actions