Improved comprehensibility of Lava programs

Particularly the following features promise to improve the readability and comprehensibility of Lava programs:

  1. Lava is a small language all of whose constructs can be represented by a limited number of tool buttons of the LavaPE programming environment.
  2. The absence of conventional loop constructs and the single-assignment nature of Lava have the highly desirable consequence that loops have to be replaced with recursive functions. Therefore, Lava programs will typically consist of many small functions and will not contain large and obscure nested loop constructs.
  3. The single-assignment nature of Lava, in combination with the absence of global variables and "static" member variables and functions, clarifies the data flow of Lava programs in a similar way as abandoning "go to" has clarified the control flow of programs.
  4. Declarations are separated from executable code; they can be nested to any depth and grouped into packages. The top layer of the Lava declaration tree is reserved for the really basic primary declarations; subordinate auxiliary notions are hidden on lower tree levels, which the programmer will open in the Lava declaration tree view only if required. To keep the semantics of nested declarations as simple and their arrangement as flexible as possible, nesting of declarations is used in Lava declaration trees only as a means to reflect the primary and subordinate nature of declarations; it does not imply any special semantic relationship between layers of nesting (unlike, e.g., the "inner classes" of Java).

    Note, however, the "sealed" nature of implementations and opaque packages, as well as the role of Lava patterns as a closed scope or domain of visibility for the contained virtual types.
  5. The distinction between immutable value and variable state objects has been introduced primarily as a means to emphasize the quite different role of these objects in the context of the respective application. Following the traditional languages, you could, of course, declare all objects as state objects in a Lava program, but you would definitely sacrifice a great deal of readability this way.
  6. Lava enforces a strict initialization discipline on object creation. All mandatory member variables of an object must be initialized within a proper initializer function of the respective (creatable) class. They can be further customized within the but-clause of the new construct. Member variables of value objects cannot be changed any more after leaving the new construct.
  7. Formal parameters of functions are clearly separated into "input" and "output" parameters. This allows additional consistency checks: A function must not assign a value to one of its input parameters, whereas a value must be assigned to every non-optional output parameter in every branch of the function. (Formal parameters and member variables may be declared "optional". In this case they may assume the special default value Ø, which means "undefined".)
  8. The overridable type parameters of Lava packages and classes facilitate the composition of large applications and components from rather small reusable design patterns. They render explicit type casts superfluous and elevate Lava programs to a new level of static type-safety in this way.
  9. Lava support for multiple inheritance is restricted to the semantically less problematic case of "shared base classes". Multiple inheritance is important since it allows us to equip complex objects with separately implemented capabilities. This is particularly useful on the top level of entire applications or components. Here multiple inheritance is highly welcome as a more appropriate substitute for "code generation wizards", since it is much simpler to modify the list of base classes of a class than to edit the generated program text in order to revise the set of capabilities to be supported by the application or component.
  10. Furthermore, multiple inheritance allows us to decompose a large class into many small ones, whose implementations may then be provided separately, even in separate files. (By comparison, recall: If a Java class implements many interfaces then the implementations of all member functions of all those interfaces are contained in this same class declaration/definition within one single file.)