The programming language standards scene, ten years on Paper 9: Ada
John Barnes 11 Albert Road, Reading RG4 7AN, UK
Abstract
This paper, one of a simultaneously published set on ten years of activity in programming language standards, describes the developments in standardization of the programming language Ada which have taken place in the period 1983-1993.
Key words: Programming languages; Standardization; Ada
1. Introduction
This paper is one of a set published simultane- ously in a special issue of Computer Standards & Interfaces under the general title The program- ming language standards scene, ten years on. This set of papers updates The current programming languages scene published in 1983 in what was then the journal Computers and Standards [7]. That in its turn updated Part 1 of the book Programming language standardisation published in 1980 [10]. This set of papers covers the period from 1 May 1993 (the reference date of the 1983 set) to 1 January 1994. This update, for the pro- gramming language Ada, takes the story on from Paper VI I IA of the 1983 set [13].
2. Background
Many programming languages emerge from an academic or industrial research laboratory as the
result of the vision or need of an individual or a small group. After experimentation and evolu- tion, the software is taken up by entrepreneurs who then adapt it for the market. Various ver- sions usually evolve and after some time the users become irritated by a lack of definition and portability; a standard is then developed. Conver- sion of products to conform to the new standard is often a painful process, and indeed full con- formity may not be obtained because of the excit- ing extras offered by some vendors. The situation tends to r emain chaotic. This pattern is that followed by Pascal and C.
An alternative approach is to design a lan- guage in the way that software is supposed to be engineered. The first step is thus to define the requirements and then do a design followed by the implementat ion with perhaps an intermediate prototype to check feasibility. This is the route followed by Ada, as described in detail by McGettr ick [13]. The requirements in the case of Ada were defined by the United States Depart-
482 J. Barnes/Computer Standards & Interfaces 16 (1994) 481-485
ment of Defense [8]. Their prime goal was porta- bility and uniformity arising from their appalling experience in the 1970s with many languages and many variants. Uniformity and portability and static parametrizat ion (genericity) were designed to provide reuse and thus long term cost savings.
Ada became an ANSI standard in 1983 [3] and an ISO standard in 1987 [11]. It is very appropri- ate to consider the position of Ada now, at the beginning of 1994, because the ISO and ANSI standards are in the final stages of revision - the ISO Commit tee Draft [5] was issued in Septem- ber 1993 - and it is thus likely that Ada 9X (the codename for the revised version) will in fact be Ada 94.
3. The Ada 83 standard
The 1983 standard has been praised for strik- ing a good balance between esoteric precision (suitable for the compiler writer) and readability (suitable for the programmer). Unlike most lan- guage standards, many programmers actually read the standard, and although undoubtedly not ap- propriate for learning the language, it is not too obscure as a reference work.
However, like all human efforts, it contains a number of errors and curiosities. A working group, more recently known as the Ada Rappor- teur Group (ARG), has studied some 800 issues since the publication of the standard and made recommended interpretations (Ada Issues) which have since been approved by the appropriate ISO group as being the official interpretation.
Getting the correct balance between clarifica- tion and helpful reinterpretat ion (changing it when ridiculous) was not always easy. Sometimes the standard said something which was patently incorrect. Perhaps the most interesting reinter- pretation is the issue of the two exceptions Nu- mer i c Error and Constraint E r r o r . T h e o r i g - inal expectation was that these exceptions could be crisply distinguished (N u m e r i c E r r o r being raised if something arithmetic goes wrong such as dividing by zero, whereas Constraint Error is raised if a range is violated), but experience showed that this was not always the case. As a
consequence, implementations were advised never to raise N u me r i c E r r o r, and users were advised to treat the two as identical.
One surprising omission from the 1983 stand- ard is anything on mathematical functions, not even a humble square root. Of course the intro- duction of genericity made it not entirely obvious just how to specify such functions if conflicting objectives such as simplicity of use for the novice and flexibility for the professional were both to be met. Subsequently, work items were estab- lished which led to the evolution of distinct standards for generic elementary functions [9] and primitive functions [6]. It is interesting to observe that a lot of energy went into the design of these standard packages; it seems unlikely that the eventual design could have been achieved in 1983 when the language as a whole was designed, since the issues and the implications of the use of the language were not well understood at that time. Thus, although late, nevertheless the out- come is (at least in technical terms) rather satis- factory.
Another interesting aspect of the Ada stand- ard is that the validation process imposed a strict policy of no subsets or supersets, with the goal of portability. This did not seem to be a problem (it might be argued that the language was so large that no sane vendor would want to extend it anyway). But of course extensions did occur, al- beit through the medium of additional packages and attributes rather than extensions to the syn- tax. Such extensions were certainly allowed within the standard, but nevertheless did create in- evitable loss of portability.
4. Current use of Ada
Although Ada was originally designed for em- bedded systems applications, it has found favour for many applications where its concern for relia- bility, and especially the features for large scale programming, are important. One such important feature of Ada is that the strong typing is en- forced across compilation unit boundaries (no separate tool is required that could be circum-
J. Barnes/Computer Standards & Inter]aces 16 (1994) 481 48.5 483
vented). This ensures that Ada programs tend to behave respectably, and do not cause unexpected crashes such as occur frequently with weaker languages (such as that in which the word proces- sor being used by the author is written, which does indeed crash from time to time!). Bounded behaviour is important for the organized develop- ment and debugging of industrial strength soft- ware and especially software which is safety re- lated.
Thus we find that Ada is used widely in the defense industries of most western nations, and increasingly for civil applications. Indeed it has been estimated that over half the Ada software now being developed is for civil applications. Ada is essentially the standard for aerospace applica- tions (including NASA and ESA) and civil avia- tion authorities, and is becoming widespread in areas such as railway signalling, process monitor- ing (engines and power stations) and so on.
Although Ada has evolved its own following, it must be said that expansion into other markets has been disappointing given the important engi- neering benefits of Ada. It has been said that one hindrance to the adoption of Ada has simply been that it has 'a defence flavour' and that this has evoked an attitude among the misinformed that Ada is not for them (for political reasons) or is cumbersome (perhaps echoing the bureaucracy of government).
A realistic structural reason for the slow adop- tion of Ada is undoubtedly that it has not found widespread favour in academia. There are two genuine reasons for this. Ada compilers were very expensive in the early years, and vendors were not inclined to give them away because they needed to maximize short term income. More- over, all compilers were highly proprietary and source code was certainly not made freely avail- able for academic experimentation. Ironically, this situation arose precisely because Ada was devel- oped 'proper ly ' with requirements and by con- tract rather than by 'hacking'; there were no initial toy compilers that could be played with by students. Thc net result was that Ada was taught only by the perceptive few and thus floods of graduates have not emerged into the world versed in Ada: instcad they are versed in C. Academic
research based on Ada has similarly been limited by the lack of compiler sources for adaptation.
Some idea of the use of and availability of Ada may be gauged by the number of compilers listed in the 1993 edition of the Ada Year Book [12]. This shows 265 distinct base compilers plus 225 derived implementations. Another interesting statistic is that a popular text book on Ada has now sold well over 100,000 copies.
5. Ada 9X
Turning now to technical issues that have emerged over the past decade and which have led to the key changes embodied in Ada 9X, there were four main areas where Ada 83 proved not to satisfy users' needs. These were:
Interfacing. It had proved difficult to interface Ada 83 programs to other systems and lan- guages. A particular difficulty was the absence of procedure values which could be passed as parameters for programming call-back, as re- quired by graphical user interfaces. Object orientation. Although Ada 83 had excel- lent facilities for static abstraction (and it is the corresponding facilities of C + + which seem to be the main practical benefit of that curious language over C), nevertheless there was a strong demand for the greater flexibility provided by type extension, polymorphism and late binding. Subsystem programming. The library mecha- nism of Ada 83 had shown great benefit in enforcing strong typing across program unit boundaries. However, experience had shown a need for greater structure and visibility control at the library level, much as the block structure provides control within a program unit. This was of particular relevance to the development of individual subsystems which make up total large applications. Tasking. Ada 83 is one of few languages having mechanisms for parallelism and inter-task communication within the language itself. However, experience showed performance problems with the rendezvous mechanism in the control of shared data access; the paradigm also gave rise to problems of indeterminate
484 J. Barnes/Computer Standards & Interfaces 16 (1994) 481-485
order of arrival (race conditions) in some cir- cumstances. The first three of the above are about increas-
ing flexibility. Indeed Ada 83 was an unduly static and almost egocentric language. It was quite amazing, for example, that all procedure binding was at compile time, without even the flexibility of procedure parameters found in almost every language since Algol 60. To a very large degree the prime goal of Ada 9X is simply to add flexibil- ity to Ada 83 while retaining the reliability which is the cornerstone of Ada.
The facilities of Ada 9X which provide the extra flexibility to meet the above needs are: various additional forms of access types (access types are the Ada jargon for pointer types); type extension and full class-wide programming (OOP); and a hierarchical form of library struc- ture providing greater control over unit visibility.
An important aspect of the extra flexibility is that Ada 9X greatly reduces the need for recom- pilation, through both the type extension and the hierarchical library, while still maintaining the integrity of the program library and thus prevent- ing the building of inconsistent total programs.
In the case of the tasking model, the difficul- ties are overcome by a totally new construction, the protected object. Protected objects are a pas- sive construction providing controlled access to private data with the protection provided intrinsi- cally within the language; they have much in common with monitors and conditional critical regions. The localization of monitors is combined with barrier conditions giving a highly under- standable construction. A requeuing mechanism provides preference control and overcomes the race conditions of Ada 83. Protected objects pro- vide the high performance of raw semaphores without the difficulties associated with such low- level primitives.
Another important feature of Ada 9X is the introduction of specialized annexes. During the development of the requirements for Ada 9X [2] it soon became apparent that if all the require- ments were satisfied by a single mandatory lan- guage then it could well prove too much of a burden for compiler developers. The problem was that there were many specialized needs in
new application areas that were being attracted to Ada for its general engineering benefits. The concept of a mandatory core language plus op- tional annexes thus emerged. All the syntax is in the core language and all validated compilers must implement all of the core. Vendors can choose to implement one or more of the annexes according to the needs of their chosen markets. The annexes address system programming, real- time systems, distributed systems, numerics, in- formation systems, and safety and security. Each annex defines additional packages, attributes, pragmas and other requirements that must be implemented to meet the validation needs of the area concerned.
(Note the key phrase here: all of the syntax is in the core. This avoids some of the problems encountered elsewhere, of syntax-level incompati- bility of programs using different combinations of modules.)
In addition to the four main areas and the specialized annexes, a number of minor improve- ments have been made to existing features remov- ing unnecessary and irksome restrictions and dif- ficulties. The language also has a much enhanced standard library incorporating, among many other things, the generic elementary functions standard mentioned above that was developed for Ada 83. The primitive functions are incorporated in Ada 9X through the more appropriate medium of attributes.
Ada 9X is thus a significantly enhanced lan- guage compared with Ada 83. Nevertheless up- ward compatibility has been a prime goal throughout the revision in order to protect exist- ing investments. Indeed the overall aim has been to achieve 'minimum negative impact and maxi- mum positive impact', as stated in the Ada 9X project plan [1].
The issue of safety-critical software deserves mention. Although Ada is a large language, and many facilities are not appropriate for use in applications where verification of the software is necessary in order to protect life and the environ- ment, nevertheless the use of an appropriate sub- set of Ada for such applications is gaining mo- mentum precisely because of the intrinsic reliabil- ity of the language [14].
J. Barnes'/Computer Standards & Interfaces 16 (19941 481-485 485
The lessons of education are also being ad- dressed by the Ada community with the develop- ment of the GNAT compiler system. This will be made freely available under a 'copyleft' arrange- ment and thus provide a training and experimen- tation capability for the academic and research environment. (Copyleft means that it is protected by copyright but can be copied and distributed without restriction provided the copyright, and the 'copyleft' arrangement, is respected and maintained.)
The proposed standard is defined by the Com- mittee Draft [5]; its accompanying Rationale [15] should be consulted for further explanation. A detailed discussion of the compatibility issues will be found in [16]. Existing and potential new pro- grammers will find the latest edition of a popular textbook of value [4].
There is no doubt that Ada 9X is an outstand- ing language addressing the needs for a firm foundation for the important applications of the next decade. Much of society may be fiddling with junk software written in unsuitable lan- guages but for those that care, Ada is available for writing programs that matter.
References
[1] Ada 9X Project Plan, Office of the Under Secretary of Defense for Acquisition. Washington DC, 1989.
[2] Ada 9X Requirements, Office of the Under Secretary of Defense for Acquisition. Washington DC, 1990.
[3] ANSI/MIL-Std-1815a: 1983, Reference Manual for the Ada Programming Language, American National Stan- dards Institute.
[4] J.G.P Barnes, Programming in Ada (ph~s an ot'erHew of Ada 9XL 4th edn, Addison-Wesley, 1994.
[5] CD 8652, Programming Language Ada, I S O / I E C JTC1/ SC22 document N1451, 1993.
[6] CD 11729, Generic package of primitice functions for Ada, I S O / I E C JTCI/SC22 document N1387, 1993.
[7] The current programming language standards scene, spe- cial issue of Computers and Standards, Vol. 2 No 2-3. 1983.
[8] Defense Advanced Research Projects Agency, Depart- ment of Defense Re~luirements for High Order Computer Programming Languages - Steelman, USDoD. Arling- ton, Virginia, 1978.
[10] I.D. Hill and B.L. Meek, Programming,, language stand- ardisation, Ellis t lorwood 198(t.
[11] ISO 8652: 1987, Reference Manual.for the Ada program- ming language, International Organization for Standard- ization, Geneva.
[12] C. Loftus (ed). Ada Year Book 1993, IOS Press 1993. [13] A.D. McGettrick, Paper VillA: Ada, pp 1(17-113 of [7]. [14] I.C. Pyle, Det'eloping safe O, O'stems; a ,~uide using Ada,
Prentice-Hall 1991. [15] Rationale for the programming language Ada. ISO/ IEC
JTCI/SC22 document N1455, 1993. [16] W.J. Taylor, Ada compatibility guide, in Ada Year Book
1994, lOS Press, forthcoming.
John Barnes is an independent con- sultant trading as John Barnes lnfor matics. His current activities include working closely with Intermetrics lnc on the development of Ada 9X, which is now in its final stages. He is the principal author of the Rationale for Ada 9X, the explanatory document which accompanies the current draft standard. He was formerly managing director of Alsys ktd and previously with SPL International. John has been involved with Ada since the original
Green design in 1978. He is author of Programming in Ada, the best-selling textbook on Ada which is now in its fourth edition and which includes coverage of Ada 9X, and is chair- man of Ada UK and president of Ada Europe. In the earlier part of his career, John was concerned with RTL/2 , which he designed when employed by Imperial Chemical Industries. R T L / 2 has been a British Standard since 1980 and is still widely used in process control and similar applications.
