Avoiding Knotty Structures in Design: Schematic Functional Programming

Designers in general have used diagrams and sketches to help in the process of creation. This is particularly so for system designers whose output is a set of programs. It would seem reasonable that the conversion of diagrams directly into a program would be desirable and yet the work of Green and Petre 3–4, 13] and Citrin 2] has placed doubt on the viability of graphical programming notations. Some of this work is reviewed in this paper. The use of secondary notation and the matc–mismatch hypothesis is reconsidered in the light of functional programming. It is proposed that much of the criticism of graphical notation is due to the imperative (or process orientated) nature of programming. Many of the limitations observed in using graphical notation are lifted when functional programming is used. Eight engineering dimensions and four engineering relationships (coherences) are proposed to describe programming environments (including notation). The source of ‘knotty structures’ is identified as embedded ‘if then else’ or ‘if’ statements. On analysing both imperative and functional programs it was found that imperative programs used an order of magnitude larger number of ‘if’s than functional programs. The key to the success of a functional language as a general representation as well as its coherence with a graphical notation comes from its unique extensibility. Support for these arguments is drawn from examples of a schematic programming language used for industrial scale projects. It is concluded that the marriage between a functional language and its graphical representation overcomes most of the original criticisms of graphical programming. It is demonstrated that this combination makes a viable and expressive tool for industrial-sized applications.