Re: Get_Line problem (GNAT bug?)

["Randy Brukardt" <randy@rrsoftware.com>]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wccfybrtj5h.fsf@shell01.TheWorld.com...
> Note: I don't know of any Ada compiler that uses Text_IO to read the Ada
> source code to be compiled.

Janus/Ada did originally, back in the early days when we had a partial
implementation of everything. Once we finished the complete Text_IO, though,
the whole thing became too slow. Indeed, these days all of the compiler's IO
is done directly through the lowest of our I/O layers (we called it
"Basic_IO", it's vaguely like Stream_IO).

My two cents on this silly discussion:

(1) The definition of End_of_File requires reading ahead as many as 4
characters. End_of_Line similarly requires read-ahead in some cases. This
requirement has a significant impact on the entire Text_IO (once you've read
those characters ahead, you have to save them somewhere for future use. But
regular buffering would make Standard_Input from the keyboard unusable...).
The requirement for lookahead means that it should *never* be called on
anything that can't be buffered, like the keyboard. So using End_of_File on
Standard_Input is always a mistake.

Besides, it doesn't make sense for a keyboard to even have an EOF. Systems
that allow it - like UNIX - are more likely to cause problems because of an
accidental EOF than any possible use. Way back, we had a CP/M machine which
treated <Ctrl>-Z from the keyboard as closing the keyboard - a reboot was
required to fix it. The machine actually had a <Ctrl>-Z key!! That often
caused loss of work when the keyboard input to the editor suddenly became
closed...  End-of-file from Standard_Input is *the* classic example of an
exceptional condition that shouldn't clutter the "normal" code.

(2) The implementation of Text_IO is *very* complicated, especially by
things that are hardly ever used like page terminators, and line and page
counts. Some routines are especially bad; End_of_File is one of these.
Because of this substantial overhead, it's usually far more efficient to
read a file with an infinite loop terminated by an exception.

(3) Text_IO.Get_Line has to read a character at a time. This can be as much
as ten times slower than other methods of reading input. So, if performance
is critical, it's probably best to read and interpret the file another way.

(4) All of this behavior is required by the RM and is enforced by the ACATS.
An implementation that doesn't return End_of_File = True for a file
containing just a blank line will fail the ACATS.

(5) Does this mean that the definition of Text_IO is screwy and
over-complex? Absolutely. But there is absolutely no chance that there will
be any change in the definition of Ada.Text_IO -- it would break a large
percentage of existing Ada programs. So, unless you're designing a
replacement language for Ada, there's no point whining about it. The
definition of the language is not going to change; compilers are not going
to change. Live with it. And that means that for 99% of programs, calling
End_of_File is just wrong; handle End_Error instead. Sorry if that hurts
your sensibilities.

                                          Randy.