Interpretation is mode in which Xreate interprets given program i.e. evaluates, expands and simplifies parts of program based on information if any known at compilation time. On another hand, Interpretation is a middle man or intermediate level between Transcend and Brute levels, it facilitates communication between them by means of interpreting data of respective layers. It can be further divided into Upper and Lower Interpretations depending on interacting with which layer we are focused at the moment. main= function:: int; entry { x= "a"::string. y= if (x=="b")::string; i12n(on) {1} else {0}. y } In this example, identifier y has annotation i12(on) which indicates that compiler should use compile-time interpretation to evaluate y. After simplification, the function's result is 0 with neither memory allocations for string variable x nor any computation at runtime. There are two annotations reserved to control interpretation process: i12n(on) Forces compiler to interpret annotated expression, function, function argument. It yields error if expression impossible to interpret i12n(off) Disables interpretation for annotated expression

Currently compiler able to interpret following expressions: Atomic instructions: numbers, strings, identifiers Relational and logic operators e.g. x==true, x!=0 if, switch statements. [[#expansion|Statement expansion]] allowed loop statements. [[#expansion|Statement expansion]] allowed Functions. [[#function-call-interpreta|Function calls]], [[#partial-function|Partial function call interpretation]] index operator e.g. x= {1, 2, 3}. y= x[0], info= {planet="Earth"}. x= info["planet"]. list operators e.g. x= [1..10]. y={"day", "night"}.

Whole function body could be subject to interpretation if it only consists of interpretable expressions. 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" } The example demonstrates function unwrap which is intended to be fully interpretable as depicted by function header annotation. Obviously, the interpretable function requires all its arguments be also interpretable. In this case compiler able to calculate function's result at compile time and nothing of function's body goes to compiled code. Compiled code looks like(which also optimized out during consequent compilation phases): test = function:: bool; entry { book = "Aristotle's Politics":: string. book == "Aristotle's Politics" } The example also reveals number of similarities with a dynamically typed programming languages: Relaxed types. Notice unknType type which has not been defined. It's interpreted well because compiler does not look at type system at all since everything can be checked at compile time anyway. Interpretation mode is exactly level where relaxed type system is possible without any penalties during runtime. Introspection abilities. Notice how it's allowed to treat list fields as string keys, so functions like unwrap can get list field name as a parameter. If list does not have requested field it just leads to a compilation error and no hard to catch runtime bugs. Additional reason for an arbitrary undefined type unknType being used in the example is to ensure that no compilation occurs and everything done on purely interpretation level In simple cases Interpretation Analysis could determine that function is subject to interpretation with no annotation hints provided. 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" } The only difference from example above is lack of annotation hint for unwrap. Developer requires interpretation of book variable which in its turn depends on unwrap. In this case Analysis able to recognize unwrap is possible to interpret, so no errors occur. There are, however, more complicated cases for Interpretation Analysis: Direct recursion. Interpretation Analysis is able to correctly find out whether function involving direct recursion(in which a function calls itself) is subject to interpretation Indirect recursion. As of now for processing of indirect recursion(in which a function is called not by itself but by another function) analysis usually fails and rely on manually provided annotation hints Below is an example of a direct recursion: 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) } Function unwrap unwraps nested list until it finds desired value. No function level annotation required.

Expansion is a partial simplification or elimination of interpretable parts of certain statements. test = function(x:: int):: int; entry { comm= "inc":: string; i12n(on). y= if (comm == "inc"):: int {x + 1} else {x}. y } In this example, computation of y depends on comm and x. On one side, comm has an annotation that requires interpretation, on another side x is unknown at compile-time and can't be interpreted. In this case the only way to satisfy contradictory requirements is to expand IF statement, since there is a possibility to only interpret condition part of the statement, leaving conditional blocks unchanged. In another words, IF statement is expanded and just one of the child blocks is compiled , x+1 in this example based on already known fact that the other block would never be executed. With regard to the fact that expansion leaves some code for compilation which has to be executed later as opposed to the "pure interpretation" it can be also called late interpretation as having runtime footprint. Below more complex example of a loop expansion: 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} } } commands contains list of operations that should be interpreted as indicated by corresponding annotation. Operand x gets assigned at runtime. This is the same situation as in previous example and triggers expansion as expected. Result after expansion looks as follows: main = function(x:: int):: int; entry { x{1} = x + 1. x{2} = x{1} * 2. x{3} = x{2} - 1. x{3} } In other words, this mimics well known loop unrolling technique by putting several copies of the loop body in a row, each one for every item of a list of `commands`. As of now follow statements support late interpretation: Branching statements: if, switch, switch variant, switch late Loop statements: loop fold functions Other operators: query late

Xreate supports case when function has mixed arguments in regard to interpretation, some should be interpreted, while others - compiled. 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) } } Looking at function evaluate's signature in this example we can see only one argument code requires interpretation. This means that function evaluate is subject to a partial interpretation or in other words late function interpretation. To enable late interpretation for function at least one of its arguments should be annotated as i12n(on). What compiler does next is to generate number of distinctive function specializations. Each unique combination of interpretable argument values corresponds to its own function specialization. This should be used with cautiousness for compiler can generate a lot of code for some cases. Example above generates three different evaluate specializations as follows evaluate1= function(argument:: num):: num { argument + 1 } evaluate2= function(argument:: num):: num { argument * 2 } evaluate3= function(argument:: num):: num { argument - 1 } main= function(init::int):: int; entry { operand= init:: int. operand{1}= evaluate1(operand). operand{2}= evaluate2(operand(1)). operand{3}= evaluate3(operand(2)). operand(3) }

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 queries and configs, to name a few. It is possible to use interpretation abilities to emulate DSL. Developer can express desired functionality as a nested lists of numbers, variants and strings which then processed by partially interpreted function. Such function in its turn transforms input data into set of low level compilation instructions so there is no runtime overhead.

Analysis follows classical type reconstruction algorithms to determine which expressions are subject to an interpretation and check correctness of reconstruction w.r.t. developer-provided annotations. Analysis consists of two general parts: Inference. Infers is it possible to interpret expression based on known decisions for its arguments Unification. Assigns appropriate decision w.r.t. to a previously inferred expectations and developer-provided hints as well