Most programming languages allow programmer defined data structures (e.g. array … of …) and when there is a rich choice available (array, record, set, pointer, etc.) there is no doubt that very neat, expressive data models can be built. However there is one major drawback. That is that the syntax used for accessing each type of structure is distinctive and fixed. This has two effects. Firstly, if for example, a list structure is altered from an array implementation to a record-with-pointer implementation then every reference to the list in the program must be changed. The distinctive array reference syntax (a[i]) has to be changed to record/pointer reference syntax (p↑. field). Secondly the program becomes more machine-oriented and less problem-oriented because of the intrusion of programming details.

The way of avoiding the problems mentioned above is to think of a data structure not just as a storage area but as a collection of distinctive operations on certain data. This almost establishes the informal definition of an abstract data type (ADT)

ADT = Data Structure + Distinctive Operations

We have been using one abstract data type (the list) without naming it as such. Its distinctive operations are head and tail, ‘concatenate’ (∥) and ‘creation from elements’ (〈e1, e2, …, en〉). We have also introduced realisations or implementations of the abstract data type list in various languages – see Chapter 6. In fact in Section 6.3, Templates for FORTRAN, the implementation of LIST as a module shows the clear intention to treat the data space and the operations as an indivisible unit.

In this chapter we address the issues of coding from a PDL into various real imperative programming languages. The PDL stage described in the previous chapter contains a complete (imperative) solution to the original problem so that the coding can now be finished without reference to the original problem. The intention in this chapter is to show that the final code generation can be accomplished using coding templates. Coding templates are shown for a variety of programming languages in common use.

Templates

Coding templates are stylised translations of each feature of a PDL. The methodical application of the templates to the PDL solution will yield the final code.

For any particular final coding language, a set of (coding) templates is created to translate each feature of the PDL in use. This means for example that every ‘if’ statement in the PDL is translated in the same way. Each time the ‘if’ statement is met it is coded using the same pattern or template. The templates are different for each different final coding language. They are chosen more for generality than for elegance or efficiency. There may well be features of a final coding language that are not used in any template. In this methodology these features will never be used. This may seem an unacceptable loss at first sight. However the experience of the authors is that the features which are not used in templates are those which are less widely used anyway or not universally supported or inconsistently supported and so their omission leads to more portable programs.

So far we have only considered the construction of new programs, but of course there are very many programs which are already in existence and which we may need to use. Like much old electronics equipment they may or may not have been well-designed but in any case there is a great tendency to ‘leave well alone’ just in case they stop working.

When a program exists only in its object form (i.e. translated into machine code) little can be usefully done – decompilers, which translate a program back into a high-level language form, do exist but the resulting program is usually pretty unintelligible. Such (object only) programs should be candidates for rewriting as soon as time is available since in their current form they cannot be safely and quickly amended and this, in practice, is an ever-likely requirement.

Programs which exist in source form present a more approachable problem. Because of their age and the rapid development of programming methodology, it is likely that these programs will not have formal specifications from which their correctness could have been demonstrated. Also, in view of their preoccupation with making best use of slow and expensive hardware, it is very probable that the early programmers were not permitted the luxury of programming style. These economic factors served to encourage the production of unintelligible ‘spaghetti’ code which was very difficult to analyse and/or modify.