=Fundamentals= Xreate is created to solve //the problem//(to allow easily and conveniently write efficient and safe code) and //the solution//(by combining largely opposite declarative and imperative approaches to cancel mutual limitations, using annotations to link them together). That's the unavoidable foundation, everything else is a subject of discussions. =Implemented, but not documented yet= ==1. Versions== Versions is a language aspect to deal with mutable data. A short example: ``` name="Example 1" x{0} = {year = 1953, month = "March"}:: Date. x{1} = x{0} + {month = "February"} :: Date. //updates a single structure's field ``` `x[0]`, `x{1}` are different versions of the same variable. This is a simple trick with an idea that for all intents and purposes x{0}, x{1} behave like different variables. All analyses treat them as different immutable variables and everything looks good. However, the compiler uses the same memory's address for them making this an update of a variable. It is a hint from a developer that only one versions of an variable should be available at any time. The only analysis that knows the truth is Versions Analysis. Its task's to make sure that there is no expression that uses outdated/unknown/unreachable variable's version. An another example: ``` COUNTEREXAMPLE, name="Example 2" x{0} = 8:: int. x{1} = x{0} + 10:: int. y = x{0} + x{1} :: int. ``` Versions Analysis builds a variables's liveliness graph to track situations when it's impossible to compute an expression due to the fact that it refers to an (possibly) outdated versions or if it lost a track of the current version due to branching, etc(Example 2). NOTE: Versions feature is in a very prototype state as of now and requires additional work. =Critical Path. Most important, still not implemented aspects= ==Pointers. Memory management== As of now, Xreate does not have pointers or overt memory management. Some directions: - Memory allocation. Automatically(with manual hints via annotations) try to recognize and decide which variables where to allocate: -- Stack. -- Fixed size memory segment with possibly predefined addresses to allocate required memory really fast. -- Heap, for the cases where the reasoning can't offer anything better. - Garbage collection. Automatically(with manual hints via annotations) try to recognize and decide which variables how to collect: -- Link life time of one variable `a` to another one `b`. Once `b` is collected, collect also `a`. -- Scope based lifetime. Note, that it's not necessary the scope where the variable in question is defined. It's easy to detect that scope/function is invoked in the loop, so choosing some other scope where it's explicitly allowed to take a moment to dispose of all the built up garbage would be better. -- References counting strategy, if no other strategy applicable. ==Mutable data== Mutable data covered by Communication. Communication checks order in which mutable variables are read or written to detect value loss and other inconsistencies. Communication is still very briefly sketched prototype. In essence, pointers, variables' versions(mentioned above and Communication are crucial building blocks for the language. ==Containers and Strings== Once pointers are done, it's possible to focus on Containers. Containers is an extension to automatically choose most appropriate implementation out of an existing pool depending on the usage. The same goes for strings. For example, encountering foreign C function `strcmp(a, b)`, Containers reasoning should suggest C-type string as an implementation for `a, b` variables. On another hand, encountering internal function `StrLen(a)` which requires(via an annotation) precomputed string size, it should infer something like a Pascal-type string(with its length stored in the first byte). As of now Containers reasoning handles which structures make eager and which - lazy ones. Basically this covers whole range of different languages' constructs, techniques and approaches related to strings, laziness, generators, etc. ==Exception== Note implemented feature. More on this later. =License= The compiler is under Mozilla's MPL. This means that the code can be combined with GPL'ed software as well as with proprietary software(with condition that MPL'ed and proprietary parts reside in different files). The intention is to make compiler clearly FOSS project with an ability to use it with proprietary plugins, extensions, IDE, etc as a remote but possible option. To make this possible, contributors are free to assign their own license for their respective parts as long as it is at least as permissive as MPL(which is expected) or MIT or something of this sort. GPL license: due to the reasons above, source code of the core components may not be GPL'ed. However there are legitimate uses for GPL(or other restrictive licenses). The compiler has two distinctive backends(or even three): - Brute byte code generation backend. Class `LLVMLayer` (and all the files in `compilation` folder) - are responsible for producing a byte code (currently LLVM). If someone adds a different backend interface, notably GCC, it may have a different, respective backend's compatible license. - A logic solver backend. Class `TranscendLayer`(and files in `analysis` folder) - compile logic programs for an external solver(currently Clasp) to process and send a solution back. There are many different solvers in existence, so the same considerations apply. - A foreign interface backend - an interface to different languages. Ccurrently it's `clang` to use external C functions in Xreate. Different bridges may require different licenses.