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 context — ability to assign transcend data to a code blocks in a way that related blocks in the CFG have related contexts. Code block's context is exhaustingly defined as follows: Block's place within the code in terms of hierarchy of all its respective parents. Historical data determined by previous visited code blocks in terms of "caller-callee" relation graph. Block level annotations are used to define context and reason about it. See syntax.

//someStringFn = function:: string {...} main = function:: string; entry { context:: env(utf8). someStringFn() } In this example the annotation env(utf8) conveys some information about the block thus distinguishing it from the others, which allows to apply specific compilation rules for this block. Suppose someStringFn 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 suggestion to pick up appropriate specialization. Also there is possibility to define expected context properties: name - "...." guard:: safe { crucialOperation = function:: int {0} } main = function:: int; entry { context:: env(safe). crucialOperation() } Function crucialOperation has only one specialization safe in the example. If the context does not provide required environment env(safe)compiler can't find appropriate specialization and reports compilation error. This is a way for function to express requirements or contract to a context it works within.

Context propagation means that contexts of different blocks are connected reflecting control flow. Context of a particular code block is gathered from following sources: Local context — annotations that are defined within the block Parent context. Block's context inherits context of its parent reflecting block's place within a program. 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. Example below 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 } } demonstrates context propagation to a nested block which is exhibited by availability of a env(safe) annotation in the context of the nested block blockB despite being defined in the blockA. 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: 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) } Suppose calculate()works with values measured in different units. It normalizes each value by invoking toSI() 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, units(mm)in this example, letting functions calculate() and its callees inherit context allowing compiler to generate code tailored for specific units only.

This section is still incomplete. It will be reworked soon. Static(compile-time) context reasoning is weak 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. To solve this problem late context is introduced - embedding into compiled code certain instructions to gathered data on relevant occasion at runtime to determine exact or strong, context. Latex approach can be described as follows: 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. 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. Late parameter is used as guard for late transcend facts context consists of. 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()} } Static scope 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() } } To sum it up, context consists of two complements parts: on the one hand static(early) context, that denotes compile time inference's result and on the other hand, late(dynamic) context denotes annotations decided upon at runtime.