3.3 TEXT_IO package

When most Ada programmers think of IO, the first thing that comes to mind is TEXT_IO. Although Ada doesn't have any built-in IO instructions, the language designers realized that Ada would be used for more applications than just embedded computers. They knew many general purpose applications would require interfaces to common peripherals (disks and terminals), so they filled Chapter 14 of the LRM with some standard IO packages. These packages, such as TEXT_IO, are provided for your convenience. You may use them if you like, but you don't have to.

I often use TEXT_IO in the code examples I publish. This should not be considered an endorsement of TEXT_IO. The fact is, I don't like TEXT_IO very much. I use it because all Ada programmers are familiar with it. If I used SCROLL_TERMINAL or FORM_TERMINAL, the unusual user interface would distract readers from the point of the example.

3.3.1 What's Wrong With TEXT_IO

I don't really have many complaints with TEXT_IO as an interface to text files, but it makes a terrible user interface. TEXT_IO treats the user's terminal just like a file, and that creates input problems. Files never make mistakes, so they don't need a rub out key. Files never enter passwords that they don't want echoed to the screen. Files never want to insert or delete text. Files never want to clear a screen or move a cursor. Files never realize the program has run amok and try to send an unsolicited CTRL-C to stop the process. Users often want to do all of these things, but TEXT_IO won't let them because it wasn't designed to support users.

The second problem with TEXT_IO is that it is heavily dependent upon the host operating system. That means it works differently on different computers, which makes it difficult to move programs from one computer to another. For example, a program containing the line TEXT_IO.put_line(OUTPUT_FILE,"Some Text"); may write "Some Text" or "Some Text", depending on how the operating system service writes lines of text. This causes minor, but annoying, problems when you write a file on one computer and try to read it on another.

You get some nastier surprises when you instantiate INTEGER_IO for integers and then call get(X); to read the integer X. Suppose while entering X the user types the wrong character and uses the rub out key to delete it. Some operating system calls will respond to the editing command and pass the corrected number X to INTEGER_IO for processing. Other operating system calls will just leave the rub out character in the middle of the string of digits. INTEGER_IO will recognize that rub out is not a decimal digit and raise DATA_ERROR, which at best will prompt the user to enter the number again.

Even if the user doesn't make a typing error, there are still problems. INTEGER_IO.get(X) will read all the characters up to, but not including, the end of line marker. These characters will be correctly converted to the number X, but the input buffer pointer will be sitting just in front of the end of the line marker. If you then call get_line(TEXT,LENGTH), it will return a null string. You have to remember to write get(X); skip_line; every time you get an integer.

Since input data editing may or may not be done by the operating system called by the get procedure, you never can tell if CTRL-X will erase a whole line, or if backspace will be the same as delete. These things all combine to frustrate the user and make Ada appear to be a user-hostile language.

I got fed up with TEXT_IO in a hurry, and wrote a set of replacement user interfaces. These packages are called VIRTUAL_TERMINAL, SCROLL_TERMINAL, and FORM_TERMINAL. They don't have a lot of state-of-the-art bells and whistles (like graphics and pop-up windows) because they have to run on "glass teletype" terminals, but they do provide a portable, consistent, friendly user interface.

Contents | Next ...