\section*{Extensions to DLP} The DLP system contains a number of features not described in part I, II and III. For example options and defaults have not been treated, since they are not of importance from a conceptual point of view. Nevertheless, for actually using the system such features are of some importance. A quite different consideration is that the language DLP is still evolving. We have included the code for these extensions, since it might provide a starting point for further experiments and research.

Options

may be set for an object by a unit clause of the form which sets the option name to value. A value may be either on or off, or a number. When no value is specified, the value given is assumed to be on. Each process created for each instance of the object is initialized with the options as set for the object. Options may also be set dynamically, by a goal of the form which sets the option name to value for the process evaluating the goal. If we do not explicitly mention what values an option may take, the value is either on or off. Unless explicitly set by the user, the value of an option is zero or off. We have the following options. Further, we have three options aux1, aux2 and aux3, that may be used for other purposes. To inspect the value of an option the expression option(name) may be used, which will be replaced by the value of the option name unless the expression occurs on the left hand side of an assignment. For debugging purposes the goals debug and nodebug may be used, that respectively turn on and switch off debugging globally.

Defaults

may be used for the initialization of objects with respect to inheritance and the values of options. As an example, the command effects that all declared objects will inherit the objects boot and system, and will have their trace option set. See sections \ref{code/O} and \ref{code/Q}.

Context switches

with respect to the functionality of a process may be effected by manipulating a stack of databases. For each evaluation process, clauses that are asserted or retracted take effect only for the evaluation performed by the process itself. Such modifications do not affect the functionality of the object to which the process refers. The state of a process, that is the clauses that are active, may be saved or restored in the following way. When clauses have been asserted, the goal effects that the current database of the process is pushed onto a stack. The goal restores the old situation by popping the stack.

Process splitting

is allowed, in addition to creating a new process when asking an object to evaluate a goal. A copy of the current process can be made by using the expression new(this) or new(this@N) that simplify to a copy of the current process, in the latter case allocated at the processor node denoted by N. Such a process may be asked to evaluate a goal. For instance, when we like to use the functionality of a particular process, we may state the goal to have G evaluated by a copy of the current process.

Object to process conversion

takes place when asking an active object for a resumption. The goal sequence results in creating an object for which the constructor c(t) is evaluated, that is subsequently asked for the resumption resulting from evaluating c(t). The request to the object O is simply redirected to the constructor process for O.

Accessing non-logical variables

is facilitated by expressions of the form denoting the non-logical variable name. of the object O. C.f. chapter \ref{des/know}. We allow goals of the form to assign t as a value to the non-logical variable name of the object O.

Global non-logical variables

may be declared by unit clauses of the form in the same way as ordinary non-logical variables. These variables may also be initialized when declared. A global non-logical variable may be accessed by using an expression of the form global(name). When such an expression occurs on the left hand side of an assignment, the (global) non-logical variable name is assigned the value on the right hand side.

Clashes

between names of objects, non-logical variables, globals and options may be resolved by using the expressions obj(name) val(name) global(name) option(name) indicating that respectively an object, a non-logical variable, a global non-logical variable or an option value must be delivered.

Hiding

names local to an object may be done by indicating which names are private, with a declaration of the form which results in post-fixing the function symbols f1 and f2 with the name of the object in which the declaration occurs. The private list may contain arbitray function symbols, even for instance the function symbol ';' provided that it is quoted.

Allocation

of objects and processes is handled by node expressions. See section \ref{des/ext/alloc}. We allow the following node expressions. The parameters of both the (imaginary) tree and the (imaginary) matrix of processors may be modified by setting the appropriate options, as discussed above.