Another problem is that, whereas the general facilities required of a procedural language are reasonably well understood and likely to remain stable, the requirements for input-output are likely to change dramatically during the lifetime of Ada, as the means of communication between man and machine evolve during the next few decades.
It is clear therefore that any attempt to define a permanent and fully comprehensive set of facilities, intrinsically bound into Ada, would have been very likely to fail: either the language would rapidly have become obsolete, or it would have been threatened with frequent change, in attempting to cope with changing demands. Indeed, Fortran is an obvious example of an old language that has suffered from these problems - its built-in input-output has restricted its utility in a number of domains of growing importance.
A further difficulty with built-in input-output is that special syntactic forms are almost inevitably used: examples are the format lists in Fortran and the variable numbers of parameters of the special write procedures in Pascal. These special forms make it impossible to change the intrinsic input-output whilst retaining the normal interface to the user; it is, for example, very difficult to insert local filtering into the input-output calls for monitoring and debugging purposes (that is, to replace these calls by calls to normal procedures which in turn call write).
Having rejected the possibility of successfully defining an intrinsic, complete, comprehensive, and stable set of facilities for all input- output for all time, one could contemplate the opposite extreme view of ignoring the whole problem in the hope that appropriate sets of facilities would emerge, defined on top of the base language.
This was the view taken by Algol 60, and undoubtedly was a prime reason for the premature obsolescence of that language and its dominance by Fortran. Individual developers of early Algol 60 compilers provided their customers with quite different sets of procedures for input-output, thereby destroying the portability of Algol 60 programs, and this resulted in the fragmentation of the user base. The later provision of a recommended standard came too late to be widely used, and the language died.
Another risk with the approach of leaving all input-output to be built on top of the base language is that the absence of appropriate syntactic support can lead to an unfriendly, clumsy, and possibly inefficient set of facilities. This was certainly also a problem with Algol 60, which required a plethora of differently named procedures to cope with the demand for flexibilty in areas such as formatting.
The approach taken in Ada lies between the two extremes of all or nothing. Input-output is not built into the syntax of the language; instead, a number of standard input-output packages are defined, using the normal extension mechanisms that the language provides. As we shall see, Ada is sufficiently rich in these mechanisms to overcome the clumsiness that plagued Algol 60. This solves the problems outlined above and, in particular, ensures the portability of the mainstream of programs without compromising the needs of special applications. Furthermore, it allows easier evolution if this is needed in the future.
The main purpose of this chapter is thus to show how the Ada extension facilities described in the previous chapters have been used in the definition of the standard input-output packages. This also serves the purpose of showing, in principle, how Ada can be used to develop other sets of packages, tailored for major classes of specialized applications; this is important, since we take the view that the standard packages are indeed just one possibility, and are not designed to deal with every foreseeable circumstance in the future.