text_io considered error prone?

[Bakin@MIT-MULTICS.ARPA ("David S. Bakin")]

Dear Ada users:

I said last week I would mention this week the error-prone construct
of text_io.page.  Well, I was going to, but after playing around with
text_io some more I decided I would just call text_io itself an
error-prone construct. 

My discussion will take the form of a challenge:

Using only the I/O described in Chapter 14 of the Ada LRM provide a
program which accurately copies an arbitrary text file.  (To make it
easy, lets assume this arbitrary text file contains only the
characters in the 128 element ASCII set.)  For extra credit, make sure
it is an efficient program. 

[Now, part of the problem may be that I am using Dec Ada on VMS, which
has a record-oriented file system.  You may be better off if you are
on Unix or MS-DOS and can use sequential I/O instantiated on a
character. Still you should try it and make sure sequential I/O works
for your system, then try it using text_io alone.  Furthermore, I
arbitrarily rule that your use of sequential I/O instantiated on a
character gets no points for the extra credit:  efficiency.]

[OK, so lets assume you're using Dec Ada on VMS, or that you're going
to use text_io anyway:] 

Try your program on the following three test cases:

1.  A file which ends in a non-blank line.
2.  A file which ends in an explicit page-terminator (for Dec Ada,
    the last line in the file contains one character, an ASCII form
    feed).
3.  A file which ends in a blank line followed by an explicit page-
    terminator (for Dec Ada, the next to last line in the file has no
    characters, the last line has only an ASCII form feed).

In case you think I'm just causing trouble:  I haven't been able to
write a program using text_io that correctly handles the above three
cases.  Sequential_IO instantiated for character doesn't work since
for Dec Ada each sequential_io.read reads a record of the file. (A
reasonable interpretation of sequential_io.read for a record oriented
system.) 

By the way, because of the way unconstrained records work in Ada you
can't instantiate Sequential_IO with an unconstrained type for
element_type (like String) and expect to READ a variable length file. 
[Even if your compiler lets you instantiate Sequential_IO with an
unconstrained type for element_type.]  (Someone please correct me if I
am wrong here.) 

I ASSERT that Ada I/O should enable you to write a program that can
copy any file created with Ada I/O.  This assertion is to my mind a
reasonable inference from the first two paragraphs of the LRM
Introduction where it is asserted that Ada is to be useful for systems
programming.  OK, I want to write a text editor, or a compiler.

(Note that this is a rather weak requirement in real life, since it
doesn't even enable you to write a program which can copy any text
file on your system (much less binary files), just those which are
written by an Ada program.)  (Note that this was once a big deal for
things like Fortran compilers on IBM mainframes:  Could you write a
file using Fortran I/O which the compiler could read?  For all I know 
it is still a big deal for things like Fortran compilers.)

[Note:  If you are using a compiler which doesn't implement Ada I/O as
described in the LRM you get 0 points.  If you don't have access to
any Ada compiler, you may not be able to do this problem at all, but
if you do, make sure you are reading the LRM very very carefully.] 

-- Dave  (Bakin @ mit-multics.arpa)

[Disclaimer:  I work for Alsys, a company deeply involved with Ada,
and highly supportive of Ada as a programming language.  These
opinions are my own, not to be attributed to Alsys or any other person
at Alsys.  I too am highly supportive of Ada as a programming
language.  Nevertheless, I don't think its contradictory or wrong to be
supportive of the Ada effort and yet believe that it isn't perfect.  I
also think it useful to discuss problems with the Ada language, in the
hope that it can be improved, or that my own misperceptions can be
corrected.  This disclaimer probably won't appear on future messages I
send ... I find these disclaimers obvious and unnecessary in general
... but I thought I should mention it at least once.]