Computer program and its internal states and transitions between them can be looked at from two different points of view: control flow and data flow. Any information that can be derived from control flow is called context in Xreate. Data that can be captured from analysing control flow consists of two parts as follows: Instantaneous state or current place within the code. It's fully determined by current code block as well as hierarchy of all its respective parents Historical data determined by all previous visited code blocks Xreate allows to express Context and reason about it by employing block level annotations. See syntax.

//someStringFn = function:: string {...} main = function:: string; entry { context:: env(utf8). someStringFn() } Example shows annotation env(utf8) which conveys some information about the block thus distinguishing it from the others. It allows compiler 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. Different story with the next example. Here we want to stipulate 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 context does not provide required environment env(safe)compiler can't find appropriate specialization and halts with compilation error. This is a way for function to express requirements or contract to a context it works within.

Context of a particular code block contains not only its own annotations but also reflects parent blocks as well as previously executed blocks. It's achieved by context propagation. Context propagation means that nested blocks inherit context of parents. Moreover callee function's context inherits caller's one. Example: 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 } } This is example of nested scope context propagation. It demonstrates availability of a env(safe) annotation in the context of the nested block blockB despite being declared in blockA. More complicated case is inter-function context propagation. 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(millimeters). 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(millimeters)in this example, and calculate() and its callees inherit context allowing compiler to generate code tailored for specific units only. Context is determined by reasoning over control flow graph of a program during compilation. Let's consider example: name = "..." calcInches = function:: int { context:: precision(accurate); units(inches). calculate() } calcMillis = function:: int { context:: precision(accurate); units(millimeters). calculate() } calculate = function:: int { 0 } Client functions calcInches() and calcMillis() each define context with a configuration options for a main routine calculate(). Unlike in previous example, there are several callers with different context here. In case with several possible control flow paths each introducing different context, only path invariant context annotations could be determined at compile time. Obviously, annotations that are the same for each possible alternative are part of context in any case. It's precision(accurate) in the example above, since both client function define it. More formally, statically determined context is a conjunction of all possible contexts of a given code block. However the other annotation units(...) differs from path to path and can be determined only during runtime. Late Transcend functionality is used for this. Context reasoning employing Late Transcend called Late Context or Latex for short.

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. Other part consists of set of possible properties that depends on exact path in CFG. Such uncertainty possible to resolve during runtime once it's known which path is chosen. It leads to a necessity of having //late context// - context data gathered on relevant occasion at runtime to determine right decisions. However, for any cases it's crucial to consider //possible contexts// that is, contexts valid only under certain conditions. Latex approach can be described as follows: All possible alternative contexts for the given scope computed during compile time used as input for Latex All possible paths are numerated and specific latex parameter created to keep data about current path. Late parameter used as guard for Late Transcend facts context consists of. As of now, to convey late context data latex parameter injected into function signature as hidden parameter. 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 up, context consists of two complements parts: on the one hand //static(early) context// denotes compile time inferences, and on the other hand, //late(dynamic) context// denotes annotations decided upon at runtime. Since it is possible to determine number of possible contexts with diffent outcome decisions, it is possible to determine least size for late context data enough to identify each possible variant. (In example above, since there are only two specializons of `compute`, 1 bit is enough to convey late context data)

To return to a last example, in order to correcly determine `compute`'s context it's necessary: After such transformation signature of `executeComputation` looks like `executeComputation(__hidden_context_data__)`, where `hidden_context_data` holds data enough to determine within `executeComputation` which one of possible contexts it encountered with. Consequently, `executeComputation` decides which specialization of `compute` should be called based on `hidden_context_data` value. Only at run-time there is enough information for `executeComputation` to decide what specialization of `compute` to call.