Run-time

As already discussed earlier (Section 1.2), Unix pipelines provide a successful mechanism for the connection of the input and output of individual programs that provides (i) a standardized format to exchange data between programs (a list of strings); and (ii) a sequential composition operator to connect programs. However, pipes have several shortcomings. First of all, they lack the basic functionality to exchange data that have more structure than a list of strings. A second shortcoming is that only sequential composition of programs is provided: the output of program $A$ can be connected to the input of program $B$, but it is impossible to feed partial outputs of $B$ back to $A$. As a result, it is impossible to describe interaction and cooperation between programs very well. Both shortcomings are addressed below.

In previous work Bergstra & Klint (1996b,a) and  have already argued that the key for obtaining a flexible run-time architecture is the separation between computation--the functions to calculate application dependent values and the procedures to perform application-dependent actions--and coordination--the flow of control between the computational parts of a system. A system using this distinction is naturally subdivided into components that carry out specific services such as, for instance, storage, retrieval, transformation of data, and user-interfacing. Each component carries out specific tasks and does not rely on direct connections with other components but relies on a coordination mechanism to make such connections. In this way, the same component can be reused in many ways by using it in combination with different components. We discuss now three key aspects: coordination, representation of intermediate data, and testing and debugging.

Figure 2: Global organization of the TOOLBUS.