RE: text_io considered error prone?

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

A flippant response to Art's comment about the subject line "text_io
considered error prone" is that a construct that doesn't do what I expect
it to do when I use it is error prone for me ... and since I expect to
be able to use Ada text_io to read and write text files and it doesn't
do a good job that causes errors.

However, I will quickly concede that the thrust of my message is that
text_io is inadequate, as opposed to error prone, and maybe the discussion
can just go on from there.

By the way ... I don't understand Art's comment that I mentioned other
ways to process these files in Ada.  I mentioned using sequential_io
and commented that it didn't work on VAX/VMS.  I could further comment
that even on Unix and MS-DOS systems where you could read a file a
character at a time using sequential_io you don't have the facilities
of TEXTUAL IO -- namely, the ability to instantiate integer_io and the
rest of the textual IO modules.

Finally, even within the limitations of text_io as defined in the LRM
as Art pointed out, I really do find text_io error prone.  It took me
a long time to be able to write a file copy program to copy a text_io
file that included page terminators ... and it still doesn't handle the
difference between two output files, one which ends:

     text_io.new_line;
     text_io.close;

and one which ends:

     text_io.new_line;
     text_io.new_page;
     text_io.close;

I think those are two different files.  And VMS thinks they are two
different files ... they have different contents.  But when I read
those files with text_io I can't tell them apart.

I hope this discussion will continue under two different subject lines:

1)  text_io considered error prone?

    Use this subject line for comments related to the error-prone-ness
    of text_io WITHIN the restrictions of text_io files as defined in the
    LRM.

2)  text_io considered inadequate?

    Use this subject line for comments related to what you'd really
    like to see in an Ada I/O facility for text_io'ish files.  This
    is a reasonable point for discussion since it is clear (I hope)
    that text_io really is inadequate when you're trying to write
    system programming tools on current operating systems -- one of
    the stated goals of the Ada programming language.

For my own curiosity, are there still implementations of Ada extant
that don't use 'real' text_io as defined in the LRM?   And, are there
implementations of Ada that, somehow, go beyond text_io and the LRM
in defining I/O?  (For example, Dec Ada has a set of "mixed" I/O
packages that might be worth discussing.)

-- Dave  (Bakin -at mit-multics)