Читать книгу Rethinking Prototyping - Группа авторов - Страница 106

We define an associative-programming language as the representation of a data flow programme in a human readable textual notation. DesignScript is an associative language, and it has been carefully designed so that where possible it shares the same syntax with imperative languages and only introduces special syntax where necessary.

Imperative and associative languages share some characteristics, but in other respects diverge.

The role of different types of statements. In imperative languages there are two types of statements: Executable statements and Flow Control statements, such as for loops to control iteration and if statement to control conditional branching. Executable statements typically define the value of variable, while flow control statements define which statements are executed. In the absence of any flow control, the statements are executed in lexical order, as they appear in the source code. Executable statements are illustrated in following code fragment:

1. = 10;

2. = a * 2;

3. = 20;

Here in line 2, the value of b is computed based on the pre-existing value of a defined in line 1. As an imperative language, a subsequent change to the value of a (in line 3) has no effect on the value of b.

In a dataflow application, this logic might be represented in Fig. 6:

Fig. 6a left, the initial graph, and Fig. 6b right, the subsequent state of the graph

The user does not have to explicitly command that the value of b is recomputed. He expects that having once define the relationship between b and a, that the value of b will be automatically recomputed if the value of a changes.

The graph, and the user’s interaction with the graph, can be given a corresponding representation in an associative language.

1. = 10;

2. = a * 2;

3. = 20;

Note, that these statements are exactly the same in both, the imperative and associative languages. However, in an associative language these statements represent more information than the equivalent executable statements in an imperative language because these statements capture the graph dependency as persistent associative relationships. Also there are important differences in execution of the same statements in the two languages.

Here in line 2, the value of b is computed based on the pre-existing value of a defined in line 1. In associative language (as in the graph), a subsequent change to the value of a (in line 3) will force the computation of the value of b (i.e. the re-execution of line 2) with no additional intervention on the part of the user. In associative languages there are no separate flow control statements. Flow control is defined by the graph dependencies.

Liveness of the Language: If a change is made to a programme written in most imperative language, then typically the whole programme must be re-complied and re-executed. However, dataflow applications - and therefore related associative languages - are live, in the sense that after initial execution, the programme is maintained in memory so that a change to a variable may only result in a partial re-execution of the programme. Which statements are to be re-executed depends on the persistent associative relationship and the topological ordering of the statements.

Use of Collections: Associative languages usually provide a way to handle collections using built-in replication techniques. This avoids the user having to write for loops to iterate through collection, and therefore reducing the need for the user to learn about for loops and iteration before using the language.

The distinction between imperative and associative programming is illustrated by the following example (Figs. 7-8). First, the designer is already completely familiar with imperative programming, then he can program exclusively in an imperative style (Fig. 7).

Fig. 7 A simple computational design model implemented in an Imperative style of programming.

Fig. 8 A simple model implemented in an associative style of programming. Notice the reduction in the number of lines of code compared to the equivalent imperative code version. This is due to the use of ‘replication’ to handle the building of the collections of construction geometry rather than the use of iteration with ‘for’ loops found in the previous Imperative style of programming.