Unlike the very first wave of Ada books, this one is (fairly) large. The extra size and time spent writing the chapters gives it the advantage that it does not just leave you with syntactic production rules from which you have to figure out all the possible elegant nuances. Depending on how hurried the reader is, there is the possible downside that Mister Young's helpfulness will take you over a week to read through.

In the preface dated May 1984 it is pointed that the book "has been completely updated" to adhere to the standard. On the whole, I am pleased that this edition does not try to pass off pre-standard features as current unlike other early Ada material I have reviewed for C Vu , but the author did not get round to culling the sentence "The Ada language will have an international standard and this standard will be rigorously enforced" in Chapter 9.

A common unwelcome distinction between Ada books and books for other languages is the quantity of programs printed on the pages. Strictly speaking, the book under review also has a minimal number of full programs to be fed unaltered to a compiler, but procedures or packages given as examples can in some cases be more readily presented in a suitable form to a compiler by an eager student than those in other Ada books.

Originally intended for students, the book in its revised edition is also aimed at professionals. Even with its exercises and selected solutions, I think that an unsavoury lesson is taught to students by this book. Most pervasively, he has used obscure abbreviations for identifiers despite preaching length specifically for identifiers. Many people code like this anyway and would not use Ada nor COBOL because of their reputations for long-windedness, but Mister Young repeatedly ignored his own policy on the matter. I would like the brevity of C's/C++'s pre- or post-increment operators (we do not yet get into

++i

versus

i++

disputes) as it does save one the worry of having to check every character in the same long identifier twice. Other terseness is not necessarily something to encourage (but as with styles, if the language does not enforce it then a sneaky programmer can get through all other barriers) even if enshrined in the appendix of The Practice of Programming by Kernighan and Pike.

(Maybe I am about to drift into a tangent here... Rob Pike and Brian W. Kernighan sensibly chose the "sobering experience" of trying all the C programs in TPoP on three compilers. Many Ada programmers seem to only try one. Perhaps these people still have a habit from when their whole company could barely afford a single license, or they are unaware that both versions of Ada specify undefined behaviour.)

About the only other example of Young going against his own advice is the use of an exceptional handler for nominal, typical control-flow. Many more people would disapprove of this, but generated machine code is unlikely to use more fragile branching mechanisms for exceptions than for popular program-flow paradigms.

As I said earlier, S.J. Young does not just present a bare lexical introduction from which you would have to determine what the language is really capable of and how one might best exploit its expressiveness. This is one reason I think An Introduction to Ada is a good book. One area I liked was its treatment of arrays. Somehow though, Young managed to never directly point out that array assignments can be made! At times not the most boastful of Ada advocates, perhaps he is a little guilty of underselling.

There is a noteworthy hint given in the chapter on tasking. The declaration

declare
DI: RESOURCE renames DISC_CONTROL(I);

where

DISC_CONTROL

is an array of tasks of type

RESOURCE

might not seem insightful at first. Paragraph 8.5(15) of ISO/8652-1987 already tells you that this is legal. What he was pointing out though is that

DI

is quicker to call because the indexing operation is only carried out during the renaming. Therefore if one member of the family in particular is often accessed, processor usage may be profitably spared.

Paragraph 8.5(16) of the standard has a trick for imitating renames , which Young redisplays in Chapter 9 of his Ada 83 textbook. So this is a trick already in the public domain and there is nothing special he adds to it, but more people might be fully awake when they read it from a textbook instead of an ISO standard.

The book does not spend a great deal more than is just necessary to introduce most aspects of the language, so when tips such as those mentioned above are not given, there may be room for exploration of what can be written in the language. Sometimes though, people decide to restrain themselves from the best solution in the interests of keeping everything clear and obvious for their less expert workmates. This kind of concern can have its place, an example of such a case was mentioned on the Team Ada email list earlier this year.

In the last 100 or so pages before the appendices, there are a number of mistakes in sample sources. Three of the six I spotted were missing closing parentheses.