stt@ada-uts.UUCP (09/20/85)
I have found OUTPUT using Text_IO quite adequate. My major gripe is that they have made no provision for controlling when the output REALLY goes to the external file/device (i.e. ability to request a buffer flush). Text_IO Input is an implementer's nightmare, if you want it to be usable on an interactive terminal, while still following the correct semantics w/r/t end-of-line, end-of-page, end-of-file, line numbers, etc. The solution we have adopted is essentially a "lazy" evaluation of all interesting state information, until the user actually requests it. So, the rule that when skipping an end-of-line marker, you should skip an immediately following end-of-page marker, is deferred until the user actually asks about end-of-page, or asks the line number, or asks for another character. The "obvious" implementation would have the effect of stopping the program at the end of each line of input, waiting to find out whether the user will type an end-of-page marker next. Because the implementation does not follow intuitively from the specification, I have the feeling that the input "model" is still not right, and still suffers from its Pascal heritage. Since Ada has adopted the ASCII/ISO character set, it would have been reasonable to simply specify the characters to be used to represent end-of-line and end-of-page. A LOOK_AHEAD routine should have been defined, which returned the character which followed (without advancing past it), independent of whether it was a graphic character or a control character, as well as returning a boolean to indicate end-of-file. A SKIP_CHAR routine should have been provided to advance past it. Then END_OF_LINE, END_OF_PAGE, and END_OF_FILE could have been defined and implemented in terms of LOOK_AHEAD. Finally, the need for multiple look-ahead should have been removed. End-of-page would be true only if the next character were an end-of-page marker. End-of-file would be true only if there were no next character. A single character LOOK_AHEAD is all that most lexers need, and providing it in TEXT_IO would have eliminated an extra layer of hassle. For record-oriented systems, an end-of-line marker character should have been specified to be substituted for end-of-record. Instead, Text_IO seems to be attempting to accomodate both stream-oriented and record-oriented views, which cripples it. Stream-oriented is much more flexible, and the model should have been consistently stream-oriented. S. Tucker Taft (617) 661-1840 inmet!ada-uts!stt c/o Intermetrics 733 Concord Avenue Cambridge, MA 02138