=Fundamentals= Xreate is created to solve //the problem//(to allow easily and conveniently write an efficient and safe code) offering //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 but really aren't. 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 the only one version of a variable should be available at any given 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 (counter)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 version or if it has lost a track of a 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, but 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 a 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's 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(described 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 the most appropriate implementation out of a pool of existing ones, depending on the usage. The same goes for strings. For example, encountering foreign C function `strcmp(a, b)` the Containers reasoning should suggest C-type string as an implementation for `a, b` variables. On the other hand, if it encounters internal function `StrLen(a)` which requires(via an annotation) implementation to have already stored 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 to make eager and which lazy ones. Basically this covers a whole range of different languages' constructs, techniques and approaches related to strings, laziness, generators, etc. ==Exceptions== Not implemented feature yes. More on this later. =Not implemented features yet. Do not belong to the Critical Path= - Type inference - Numbers - Why subsytem - Time machine - Diagnostics =License= The compiler is under Mozilla's MPL. This means that the code can be combined with a GPL'ed code as well as with a proprietary code(under condition that MPL'ed and proprietary parts reside in different files). The intention is to make the compiler clearly FOSS project with an ability to use it with proprietary plugins, extensions, IDE, etc as a very remote but possible option. To make this possible, the contributors are free to assign their own licenses for their respective parts as long as license in question is at least as permissive as MPL(which is expected) or MIT or something of this sort. Anyway, not a single stroke will be used without a fully informed contributor's consent. GPL license: due to the reasons above, a source code of the core components may not be GPL'ed. However there are still legitimate uses for GPL(or other restrictive licenses). The compiler has two distinctive backends(or rather 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 an interface to a different backend , notably GCC, it surely 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 out there, so the same considerations apply. - A foreign interface backend - an interface to different languages. Currently it's `clang` to use external C functions in Xreate. Different languages' bridges may require different licenses.

=Fundamentals= Xreate is created to solve //the problem//(to allow easily and conveniently write an efficient and safe code) offering //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 but really aren't. 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 the only one version of a variable should be available at any given 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 (counter)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 version or if it has lost a track of a 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, but 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 a 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's 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(described 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 the most appropriate implementation out of a pool of existing ones, depending on the usage. The same goes for strings. For example, encountering foreign C function `strcmp(a, b)` the Containers reasoning should suggest C-type string as an implementation for `a, b` variables. On the other hand, if it encounters internal function `StrLen(a)` which requires(via an annotation) implementation to have already stored 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 to make eager and which lazy ones. Basically this covers a whole range of different languages' constructs, techniques and approaches related to strings, laziness, generators, etc. ==Exceptions== Not implemented feature yet. More on this later. =Not implemented features yet. Do not belong to the Critical Path= - Type inference - Numbers - Why subsytem - Time machine - Diagnostics =License= The compiler is under Mozilla's MPL. This means that the code can be combined with a GPL'ed code as well as with a proprietary code(under condition that MPL'ed and proprietary parts reside in different files). The intention is to make the compiler clearly FOSS project with an ability to use it with proprietary plugins, extensions, IDE, etc as a very remote but possible option. To make this possible, the contributors are free to assign their own licenses for their respective parts as long as license in question is at least as permissive as MPL(which is expected) or MIT or something of this sort. Anyway, not a single stroke will be used without a fully informed contributor's consent. GPL license: due to the reasons above, a source code of the core components may not be GPL'ed. However there are still legitimate uses for GPL(or other restrictive licenses). The compiler has two distinctive backends(or rather 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 an interface to a different backend , notably GCC, it surely 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 out there, so the same considerations apply. - A foreign interface backend - an interface to different languages. Currently it's `clang` to use external C functions in Xreate. Different languages' bridges may require different licenses.

=Fundamentals= Xreate is created to solve //the problem//(to allow easily and conveniently write an efficient and safe code) offering //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 but really aren't. 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 the only one version of a variable should be available at any given 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 (counter)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 version or if it has lost a track of a 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, but 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 a 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's 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(described 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 the most appropriate implementation out of a pool of existing ones, depending on the usage. The same goes for strings. For example, encountering foreign C function `strcmp(a, b)` the Containers reasoning should suggest C-type string as an implementation for `a, b` variables. On the other hand, if it encounters internal function `StrLen(a)` which requires(via an annotation) implementation to have already stored 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 to make eager and which lazy ones. Basically this covers a whole range of different languages' constructs, techniques and approaches related to strings, laziness, generators, etc. ==Exceptions== Not implemented feature yest. More on this later. =Not implemented features yet. Do not belong to the Critical Path= - Type inference - Numbers - Why subsytem - Time machine - Diagnostics =License= The compiler is under Mozilla's MPL. This means that the code can be combined with a GPL'ed code as well as with a proprietary code(under condition that MPL'ed and proprietary parts reside in different files). The intention is to make the compiler clearly FOSS project with an ability to use it with proprietary plugins, extensions, IDE, etc as a very remote but possible option. To make this possible, the contributors are free to assign their own licenses for their respective parts as long as license in question is at least as permissive as MPL(which is expected) or MIT or something of this sort. Anyway, not a single stroke will be used without a fully informed contributor's consent. GPL license: due to the reasons above, a source code of the core components may not be GPL'ed. However there are still legitimate uses for GPL(or other restrictive licenses). The compiler has two distinctive backends(or rather 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 an interface to a different backend , notably GCC, it surely 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 out there, so the same considerations apply. - A foreign interface backend - an interface to different languages. Currently it's `clang` to use external C functions in Xreate. Different languages' bridges may require different licenses.