From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 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 List-Id: [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)