This book is not intended to teach you the Ada
programming language. You should already be familiar with
Ada syntax and semantics. My goal is to share with you the
experiences I've had using Ada in engineering applications.
I hope these pages will help you avoid some common pitfalls.
Most of all, I hope I can help you fill your bag-of-tricks
with some reusable Ada routines.
1.1 Organization and Content
The rest of this book is divided into four main topics. The first topic is numeric considerations. The examples Chapter 2 illustrate the things you need to think about whenever your program does non-trivial calculations. This includes obvious things like how many bits you will need for integers, and what floating-point data type to use, but it also includes some things you probably haven't been exposed to before. The idea of letting the compiler check the consistency of the dimensional quantities in equations is a new innovation made possible by the Ada language.
Another difficult problem most programs have to deal with is the user interface, so it is the second topic. People aren't as predictable and consistent as mechanical devices are, which makes user interfaces difficult to design. This is an area with a lot of potential for reusable software. Chapter 3 is full of utility routines that I think you will find very useful.
Contrary to what you've often heard, the whole is more than the sum of its parts. Even if you have all the pieces, they aren't worth much if you don't know how to put them together. Chapter 4 shows several examples of small-scale programming, and one example of more rigorous software engineering, which is the third topic.
The last topic is testing. I saved it for last because writing code is easy; making sure it works correctly is hard. Over the years I've used a variety of methods to check code, and Chapter 5 talks about them.
A quick peek at the back of the book shows there are hundreds of pages of examples of Ada source code. The first examples are simple, and they get more complex as you read toward the end of the book. "Complex" has come to mean "difficult", but that's not the case here. The later examples are properly called complex because they were composed by combining the smaller building blocks found near the beginning to create bigger, more powerful, building blocks. This means it will be easiest to understand if you read the book from front to back without skipping around.
When choosing the examples, I didn't go through the list of Ada reserved words and try to come up with an example for each one. If I did, the first example would have an abort statement in it, the second would show how to use the abs operator, and so on. These contrived examples wouldn't do much more than show syntax, which you should already know.
Contrived examples often do things strange ways just for the sake of illustrating a point, and this sometimes teaches bad programming habits. For example, recursion is often demonstrated by recursively computing N factorial (N! = N * (N-1)! until N = 1). That's a good way to show recursion, but a terrible way to compute N factorial. Students often miss the point of the example. If the homework assignment is to write an excellent program to compute N factorial, guess how most of the students will do it. (Hint-- They don't use a loop!)
I used practical examples with real applications, so the examples determined what Ada features were demonstrated and their order of appearance. This approach gives the most exposure to the most commonly used Ada features, and less emphasis on the less important ones. The only two Ada features that didn't get a fair shake from this approach were tasking and access types.
There are so many things that need to be considered when using tasking, I might be able to devote almost an entire book to it. I wanted to avoid any discussion of tasking because I didn't want to get started on a topic I didn't have space to adequately explain. (It turned out that I couldn't avoid tasking completely, so you will find a brief example in the VMS package.)
Access types are most useful for solving problems in
very specialized areas. The only time I've ever needed
access types was for an Artificial Intelligence (AI)
problem. My AI example is an excellent showcase of access
types, but it requires too much technical AI background to
fit in this book, and it isn't quite ready for publication
yet. That's why you won't find any examples of access types
in this book.
1.2 Figures and Listings
All the figures and listings are at the back of the book for easy reference. Despite their location, they are meant to be read right along with the text. Package specifications include comments that tell what the routines do, and how to use them. Comments in the package bodies tell how the algorithms work. I don't generally repeat this information in the body of the book. The body of the book tells what the other alternatives were and why I made the decisions I did. If you don't read the figures and listings when they are first mentioned in the text, you might not understand the discussion.
There is a distinction between figures and listings.
Both contain code, but the code in the figures are not
intended to be used in your application programs. Some of
the figures are examples of what not to do. Other figures
are examples of correct style, but are intentionally
incomplete (to avoid obscuring the main point of the figure
with necessary but extraneous details). Listings, however,
are complete. They have been compiled and tested on at least
one validated Ada compiler, and may be useful in your
application programs. The source code for all the listings
(but not the figures) can be purchased separately on a
floppy disk.
1.3 Copyright
It would be foolish for me to write a book revealing many of
my software secrets, and then say to you, "You may buy this
book only if you promise never to use any of the code I'm
going to show you." It would be even more foolish of you to
buy the book under those conditions. I expect (and want) you
to use the code shown in the listings in your programs. If
you make a bundle of money doing that, good for you. You
don't owe me any royalties.
1.4 Liability
As far as I know, there are no errors in the listings, but I have no control over them once they leave my computer. There may be a typesetting error, or you may miscopy the listings. The source code disk may be defective, or your disk drive may introduce undetected errors when reading it. You may modify the listings in some way that introduces an unexpected side effect. You could compile them with a defective compiler. There may be a strange run-time dependency in your computer that my computer doesn't have. There are all sorts of things that could go wrong, over which I have no control.
Since I have no way of knowing how you are going to use
the code, what compiler you are going to use to compile it,
what target machine it will run on, or how you are going to
modify it, I can't guarantee that it will work in your
application. You may use my code at your own risk but you
have to take the responsibility for the consequences
yourself.
1.5 Ada not ADA
Everyone reading this book should know that ADA is the American Dental Association and Ada is a programming language named in honor of Ada Lovelace, the first programmer. Ada was born in 1815, and that's the reason the Ada Language Reference Manual (LRM) is MIL-STD-1815A. In light of this distinctly feminine background of the language, I consistently use feminine pronouns when referring to Ada. To avoid confusion, I use masculine pronouns for humans (programmers and users) of either gender.