diff --git a/documentation/index.xml b/documentation/index.xml index 4f76967..1388e4b 100644 --- a/documentation/index.xml +++ b/documentation/index.xml @@ -1,216 +1,249 @@ <?xxe-sn 2b06cb2u4g0 2?>Xreate Manual 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, - 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. + Here "high level" is all about a developer + oriented side focused on 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 three + dimensions: efficiency, safety, and flexibility. 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. Blending + features of seemingly incompatible programming paradigms is a basis of + Xreate's design principles. To achieve the aforementioned design goals, - Xreate employs three distinctive layers: + Xreate consists of three distinctive layers: Brute. The lowest layer is called Brute — 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. + instructions such as arithmetic, branching, input / output, etc. Transcend. - 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 - Transcend. 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. + Brute 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 declarative + type layer called Transcend. + Transcend is a logic reasoner that is appropriate to do management-type + work — it analyzes, oversees and controls Brute by guiding compilation + process. More precisely, 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. + Unlike usual static analysis tools, Transcend directly controls + compilation(see Basic + Example) and able to make decisions even based on data available + only at runtime(see Late + Transcend) Interpretation. There is also Interpretation — 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. + used as a contact point and interpreter between Brute and + Transcend. On a syntactic level, Xreate is a procedural language with extensive use of annotations - — arbitrary unconstrained metadata that software developer can attach to + — arbitrary unconstrained metadata that a 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 + completely invisible for the compiler proper and used by Transcend more as a suggestion conveying additional information. "a different language constructs": если подразумевается "конструкции разных языков", тогда лучше "different languages' constructs". Если конструкции языка, в целом, то тогда артикль a не нужен - 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. - - Thus Xreate - places key emphasis 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 - and exploitation - chapters, and mutable structures covered in communication. + There are several extensions already + implemented to give a feeling what does this structure can be used for. + Containers + chapter describes that it is possible to reason about and automatically + choose the most appropriate data structure's implementation depending on how + it is used in the code. Look at the example below: + + x = [1, 2, 3]:: [int]. + + Container x + does not have well defined implementation just yet. Only by looking how it + is used throughout the code, the compiler is able to decide how exactly to + store container's data. + + Interaction of different components and joint + use of external resources is covered by Exploitation: + + dataA = readFromFile("/some/file"):: string. //here a file is accessed for the very first time +dataB = readFromFile("/some/file"):: string. //this is the last time the file is accessed + + Exploitation reasoning allows to determine + when it is the first, + last access to a file, in other + words, infers access order. As a result, using the data it is possible to + automatically initialize / destruct related resources. + + Virtualization + reasoning enables access control if and + when it is needed only. Example: + + openFile("/some/file"):: string; assign_sizo(zoneA). +openFile("/some/file"):: string; assign_sizo(zoneB). + + If the compiler recognizes file access from + the different zones, as in this example, it applies an appropriate + virtualization strategy enough to ensure that instructions that belong to + different zones do not interfere with each other. + + Unlike "pure", academic languages, Xreate + targets safe and reliable usage of effectful computations such as IO that is + covered above as well as mutable structures described in the Communication + chapter. + + Note, that the described extensions are not + part of the compiler and developers can write their own custom transcend + rules to cover other aspects.
<?xxe-sn 2b06cb2u4g0 4?>Basic Example 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 + 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 a 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 that developer specifies two + in its signature. There are also two functions with the same name + div called specializations. + 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 div + have iAmVeryFast and iAmVerySafe + guards, respectively. Let's say that a code author writes 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 - polymorphism + implementation since it checks division by zero, being "unacceptably slow" + due to an extra check instruction, though. This is a basis of polymorphism — client's code test is able to work with any specialization, and compiler must decide which one to invoke with the only hint it has — annotation iAmVerySecure in the function test's signature. "provides two specializations" - возможно, лучший вариант "designates/assigns/allocates two specializations". Или даже просто specifies/indicates. (PS заменил на specifies) "unbearably slow" - я бы заменил на более нейтральное "too slow". Unbearable - это скорее об ощущениях человека. Или, если под "unbearably" имеется в виду "недопустимо медленный", тогда - unacceptably slow. All annotations (except entry) are custom defined by developer itself. - This is when transcend comes into play. By + This is when Transcend comes into play. By adding a 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 the other specialization isn't even compiled. the, потому что их всего две. 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 + 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.