Hoogvorst dataflow(ID:7375/hoo003)Dataflow language by Hoogvorst References: The current programming languages even those called high level languages are actually very far from the formalisms used in algebra, physics,etc... After a first description with the adequate formalism, one must write again his problem and has to respect the programming language constraints. In most of cases, this programming step is not a mere translation and requires much efforts. Furthermore, the program being written, the user has no warranty for its correctness. Now, new high level languages are being developed and offer program proving possibilities. Among them, the language defined by J. Arsac, is an algorithm description-directed high level language, very close to the algebraic notations. At the beginning, this language was not considered as a programming language, because it currently requires too much processing time and besides it supposes a great amount of softwares on available conventional machines. The problem we had to cope with is to get an adequate computer architecture for an efficient execution of such a language. In this case, a direct execution machine seems to be a very attractive solution. Extract: The language peculiarities The language peculiarities The language defined by J. Arsac presents great similarities with LUCID [2,3]. Actually, these two languages were conceived to offer easy program proving. Moreover, they are unconventional because the order of statements is irrelevant and because any instruction is considered as an equation. Nevertheless, if LUCID has still some writing similarities with a conventional programming language, the language we use has a different form because it was defined to be as close to the algebraic notations as possible, so that the user would have no execution considerations to look upon. In the following sections, we shall set off the language particularities, some of them being also found in LUCID. 2.1. Definition unicity In this language, every instruction actually represents the definition of a variable, so that any instruction gives the manner to get the variable value. Moreover, each variable must only be defined once and only once. This implies that the value assigned to a given variable is unique: there is biunivocity between the variable name and its value. So, we can consider an instruction as an equation. This property allows substitutions within the program: any variable occurrence can be replaced by its definition. 2.2. Lack of control schema In the usual high level languages (Algol, Fortran, etc...) the control schema is explicit: the algorithm represented by a program depends on the program instruction order. Any alteration of the instruction order may modify the algorithm itself. Thanks to the definition unicity (see § 2.1.), we do not change an algorithm by changing the definition order, even if these definitions contain conditional expressions. The instruction effect only depends on its content; it does not depend on its position in the program. So, the instruction order is irrelevant. 2.3. Recurrences The language gives the opportunity to use the recurrences. To describe a recurrence, we need: - one or several recurrent definitions - a recurrence stop condition - the recurrent variable initialization. As it is done in the algebraic language, the recurrent variables are indexed: two occurences of a given variable name,having distinct indexes, are then considered as two different variables, so that we should respect the definition unicity. No recurrence delimiter (analogous to DO loops) is necessary. Moreover , the recurrent definitions need neither to be contiguous nor to be ordered. A recurrence is defined by a recurrence index: only the variable definitions indexed by a given index are involved in the same iteration. The recurrence index has initially the value zero and it is incremented by one at each recurrence step until the stop condition occurs; this condition is specified in a definition by a special operator (see § 2.5.). Moreover, the recurrence depth can be greater than one; we can use definitions having the following form: y(i) = f(x(i), y(i-l), y(i-2) .... ). To nest recurrences, we only have to index the variables with several recurrence indexes and we specify for each of them a stop condition. 2.4. Algorithm structure Any algorithm is composed of: - a header, where we find the name of the algorithm, the results, the input data - a body, represented by the result definitions and also eventually by the local variable definitions (a local variable does not appear in the header) Any definition is composed of: - a left part, representing the variable to be defined - a left part delimiter, represented by the symbol " <--" - a right part, defining the variable value. Any right part may be composed of: - either an arithmetic expression - or a selection among several computation possibilities of the value (alternant selection) - or a sub-algorithm call; in this case, the name of the sub-algorithm is followed by the adequate input data. These different possibilities can be combined with one another. in Proceedings of the 1978 annual conference 1978, Washington, D.C., United States view details |