Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!mit-multics.arpa!Bakin
From: Bakin@MIT-MULTICS.ARPA ("David S. Bakin")
Newsgroups: net.lang.ada
Subject: RE: Text_io considered error prone?
Message-ID: <850917124405.710140@MIT-MULTICS.ARPA>
Date: Tue, 17-Sep-85 08:44:00 EDT
Article-I.D.: MIT-MULT.850917124405.710140
Posted: Tue Sep 17 08:44:00 1985
Date-Received: Thu, 19-Sep-85 05:17:45 EDT
Sender: daemon@ucbvax.ARPA
Organization: The ARPA Internet
Lines: 85

[This missive contains a, well, lets call it a flame, about Ada
text_io.  If you don't want to hear about it, send mail to me now and
stop reading this message.  -- Dave]

I'm wondering a little about the silence now present on the subject
of text_io in particular and Ada I/O in general.  I thought I'd be
hearing a bit more about it.  If I'm the only one who thinks that
text_io is inadequate then at least send me some private mail saying
that you think I'm all wet and I'll shut up.  The responses to date
seem to be of the Henry Ford variety:  "Text_io does everything you
want it to do, as long as what you want to do can be done by text_io."

I still don't know the way to copy a varying length file with standard
Ada I/O.  In fact, I don't know how to read one:  Farokh Morshed told
me that the way to do it with sequential_io is to instantiate sequential_io
with an unconstrained array type, declare a large buffer (larger than
an record in the file) of that type, then loop as follows -- fill it
with a 'known' value, do a read, check the buffer from the end to see
where the 'known' value stops and thus the real data ends, then wow,
you know how long the record is, so write it.  He neglected to say
that you need to have checks off when you do it, and even so it is
probably implementation-dependent whether the I/O package raises
USE_ERROR or something else anyway.  Is everybody happy with this
solution?

Dec seems to think Ada I/O is missing something.  They implemented
some packages to do "mixed" I/O, that is, you could mix binary
integers and enum types and arrays and stuff in one file.

Rational seems to think Ada I/O is missing something.  They have
implemented some packages to do "polymorphic" I/O, that is, you could
mix binary integers and enum types and arrays and stuff in one file.

Does anyone else but me wonder why the two packages can't be the
same for the sake of portability?

Rational also has a package to do bit and byte stream I/O.  I think
that's useful too.

I'd like to be able to write a file using text_io on our VAX and
transfer it to our PC and read it with another Ada program.  And
reverse it.  Isn't that one part of program portability?  Here's
an opinion:  If text_io goes to all the trouble of specifying line
boundaries and page boundaries and file boundaries on the one hand,
and Ada goes to a lot of trouble defining the whole language to work
with the ASCII character set (e.g., STANDARD.ASCII and the definition
of string and character not even letting you get to your machine's
underlying character type), then it is surprising to me that the
definition of text_io DOESN'T include a way to transport text_io
files from one machine to another.  Sequential_io I can understand ...
you have byte-ordering problems, etc.  There are defined symbols in
the language called standard.ascii.ff and standard.ascii.lf, not to
mention standard.ascii.rs and standard.ascii.fs.  Why go to all the
trouble of defining these and ignore the definitions given to them
in the ASCII standard by letting implementations choose incompatible
ways of defining line, page, and file terminators?

OK folks, why am I complaining?  Well, the Ada language isn't fixed
for all time.  Like all other ANSI languages it'll be reviewed from
time to time and improvements suggested.  I know there is a scheme
for making comments -- you send mail to ada-comment or something, and
then you can poke around in the comment-archives and see what other
people have to say.  Only I believe that the kinds of comments sent to
ada-comment are much more precise, or at least, definite, than the
kinds of comments I'm willing to make now.  I don't know the answer
to my questions about Ada I/O ... my feeling is it needs discussion
now, we're not even at the stage of writing papers for Ada Letters
or comments to be read by the language maintenence committee.

So, I bring the matter up once more.  Now's your chance:  If you
don't think ada-info is the proper place to discuss this send me
private mail, I'll comply with the general opinion.  Or if you
think text_io isn't worthy of this much discussion, let me know that
too.  Or finally, if you think of another way for interested people
to discuss this with me I'd like to hear about it (bearing in mind
that I don't go to Ada-ish conferences to talk about it with you
face-to-face).

Remember:  I'm not interested in complaint with no purpose, I'd
like to improve Ada.  Furthermore, I'm right now using Ada to do
almost everything I want to do ... I just want to do it better, and
in this case, with standard Ada I/O of some sort.

Thanks for letting me flame on (that is, if you've read this far)
-- Dave  (Bakin -at mit-multics.arpa)