Contribution Notes

Updated 1,841 Days AgoPublic

Actions

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:

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:

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).

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.