Xreate is an open source general purpose high level programming language designed to write efficient and safe computer programs. Here "high level" has very specific meaning as 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(still unsafe) or safe(and impractical) code, but not both. Thus, the ultimate goal of the language is to allow developers to produce code with 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. To achieve aforementioned design goals Xreate has tree distinctive layers: Brute. Lowest layer is called Brute— this is code that is indented 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. Transcend. Brute level alone is not enough to constitute full fledged language since a 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 Transcend. Transcend features declarative nature that is appropriate to do management kind of work — it analyzes, oversees and controls brute by guiding compilation process. Everything that is on this level — logic or transcend facts and rules are gathered and sent to an external logic solver to make solutions that are brought back in order to guide compilation. Interpretation. And there is also Interpretation — intermediate level resembling features of dynamically typed languages that is used as a contact point and interpreter between brute and transcend and their low level and high level constructs and structures respectively. On a syntactic level Xreate is procedural language with extensive use of annotations — arbitrary unconstrained metadata that software developer can attach to a different language constructs, variables and code blocks. Annotations are completely invisible for the compiler proper and used by transcend rather as suggestions conveying additional information. Most severe and hard to resolve problems in software development stem from interaction of different components on a different levels. Each individual component often is thoroughly tested and works reliably. But combining them with complex interaction and extensive IO to build end-user software usually leads to a range of runtime errors, security vulnerabilities and performance degradation. Thus key emphasis of Xreate is on domain specific component level improvements and joint use of external resources. This aspect is covered in exploitation and containers chapters. Unlike academic languages, Xreate targets safe and reliable usage of effectful computations, such as IO, covered in virtualization, exploitation chapters and mutable structures covered in communication.

To demonstrate what Xreate is all about, basic example is given below: 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) } Here entry point of the program is a function test recognized so by the compiler because of annotation entry in its signature. There are also two functions div called specializations. Each specialization has a guard that defines condition that has to be met in order to invoke this particular specialization. In the example, specializations of div have iAmVeryFast and iAmVerySafe guards respectively. Let's say, developer provides two specializations where first is a very fast division implementation and second one is a very safe since it checks division by zero but at the same time is unbearably slow due to extra check instruction. This is a basis of polymorphism — client's code test is able to work with any specialization, and compiler should decide which one to invoke with the only hint it has — annotation iAmVerySecure in the function test's signature. All annotations(except entry) are custom defined by developer itself. This is when transcend comes into play. By adding transcend rule as shown below it is possible to associate annotation iAmVerySecure with invocation of specialization guarded by iAmVerySafe: 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). Transcend rules are written in ASP syntax — common syntax to write logic programs. This particular rule reads that for any function annotated with iAmVerySecure, certain specialization iAmVerySafe is chosen for div invocation. In this example an appropriate specialization is statically resolved, so other specialization isn't even compiled. By providing custom rules it is possible to implement any polymorphism strategy, be it statically performed or dynamically. The example demonstrates basic workflow: transcend gathers available information about a program, such as annotations and using custom rules makes decisions to guide compilation process particularly by selecting appropriate specializations as in this example.