Language

The code will be stored in repository as a linked tree in syntax-independent way. It will be based on intentional programming paradigm, allowing defining new abstractions. For example – ‘container’ may be defined as an abstraction of data that have elements which can be iterated. An abstraction will define a tree’s node, syntax for textual representation and code to convert this node into more primitive nodes, debug support and so on). See Appendix 5.

The primary language syntax will be highly compatible with predecessors – C/C++/Java/C#. It will have support for configurable strictness. For hard real-time code one may enable maximum compile-time checks to completely avoid run-time checks, plus enable unsafe operations. For conventional code many compile-time checks may be disabled to be checked at run-time. For high-level code (like scripts) all checks may be disabled, to be checked at run-time.

One of major difference will lay in extended type system. Types will be represented as a set of constraints. For instance, you may have a class String, which will have multiple types – for example, mutable and immutable strings. Types will have information about memory class of data (heap, stack, movable, immutable data and so on), about possibility of assigning NULL to a reference/pointer of this type. Types will have inheritance information (exact type, exact or child type, exact or parent type) and parameters (for parameterized types, usually containers). Array types will have information about dimension and so on.

All constraints in types may be optional. If a constraint if omitted – run-time check will be used. There will be enough of constraints to avoid all run-time checks, but preserve complete safeness of the code – of cause, design and implementation of such optimized code will be much harder and verbose. It’s going to be used for real-time and time-critical code only.

The language will be extended to provide more detailed optimization hints. This will include support of multiple levels for ‘inlining’ methods and multiple levels of ‘register’ and ‘volatile’ hints for local variables and object fields. It will be possible to provide call-convention hints.

It will have a well-known set of type kinds – primitive, wrapped values, tagged and untagged structures and unions, tuples.

Access rights will be configurable from minimal set (public/private) to fully user-defined (like ‘this field can be modified by that method only’).

A new kind of types will be added – ‘view’. The ‘view’ is like in SQL you may have tables and have several views of these tables. They will mostly be used for user-defined access rights and for security implementation. Views may be both compile-time only and run-time. Pointers to data and interface (like vtable) may be separated (that is, an interface is extracted from object’s type) for faster method’s invocation or security reasons.

There will be support for asserts, traces, call-by-contract, logging statements. In release builds these checks may be completely or partially removed. Strings in traces may be extracted, to minimize data sent by traces and memory usage or debug builds.

Middle-level features will include exceptions, classes, run-time calls dispatching (by virtual tables or pattern-matching calls), garbage collection, automatic wrapping/unwrapping of primitive values and others features commonly used in Java/.NET/C++.

Also the language will have syntax and semantic for all features noted in VM section, like objects with changeable state, closures and inner methods, untyped variables, embedded) fully integrated) engine for logical and functional programming as well as for script languages (compiled to bytecode).

Additionally to our common, configurable language, one may also use already existing languages (even highly-specialized, like for writing final automats used for complex protocols – GPRS, WAP), both directly into portable (distribution) code, or via sources of low-level part of our language (to be used as a ‘portable assembler’).

High-level features will also include native containers and others commonly used programming primitives. Code may be typed or untyped (i.e. will allow rapidly create prototype code, which can later be optimized and made safer by providing types and others constraints). There will be support of overloaded (actually - user-defined) operators and methods (since there will be no signatures, operator definitions and methods overloading will be done through name aliases). These and others high-level features will be defined through libraries of nodes for the program’s tree (according to intentional programming paradigm). See Appendix 5.

Basically, intentional programming is going to be a primary technology of the near future, and will make as big impact as OOP did. But the intentional programming is not developed completely yet. One interesting possibility will be to cooperate with IntelliJ Idea (Java IDE) team, which is actively working on this technology now. From this cooperation we can get the IDE for our project, experienced java programmers (it’s a Russian team, so they will not be too expensive), and a great help with intentional programming.