GET_LINE for interactive devices AI-00172/06 1 86-07-23 ra WJ | !standard 14.03.06 (13) 86-07-23 AI-00172/06 !class ramification 84-11-28 !status approved by WG9/AJPO 86-07-22 !status approved by Director, AJPO 86-07-22 !status approved by WG9/Ada Board 86-07-22 !status approved by Ada Board 86-07-22 !status approved by WG9/ADA Board 85-02-26 !status committee-approved 84-11-28 !status work-item 84-11-06 !status received 84-01-17 !references 83-00258, 83-00263, 83-00384, 83-00396, 83-00464, 83-00465, 83-00489, 83-00484 !topic GET_LINE for interactive devices !summary 84-12-31 An implementation is allowed to assume that certain external files do not contain page terminators. Such external files might be used to represent interactive input devices. (To ensure that such files have no page terminators, an implementation may refuse to recognize any input sequence as a page terminator.) Under such an assumption, GET_LINE and SKIP_LINE can return as soon as a line terminator is read. !question 84-12-31 When reading input from an interactive device using GET_LINE or SKIP_LINE, must an implementation always wait after a line terminator is read to see if a page terminator will also be input? !response 85-05-27 The specification of GET_LINE states that it reads characters until "the end of the line is met, in which case the procedure SKIP_LINE is then called (in effect) with a spacing of one". The specification of SKIP_LINE includes a check for whether the end of line is followed by an end of page, in which case the page is to be skipped as well as the line. Since SKIP_LINE is in effect called by GET_LINE, GET_LINE also must skip over any page terminator that follows a line terminator. When GET_LINE is called for a file that is associated with an interactive terminal, the possibility of having to skip a page terminator appears to mean that before GET_LINE can return, the terminal user must enter additional input after inputting a line terminator. If input is line buffered, a user must enter a complete second line before the first line can be processed by the Ada program. One might think this problem could be solved by "lazy lookahead," i.e., by returning from GET_LINE before checking to see what follows the line terminator and then waiting at the next read operation to see if a page terminator should be skipped. This implementation would not be correct, since a call to LINE or PAGE will return the wrong value while the lookahead is still pending (e.g., LINE should return the value 1 if the line terminator accepted by GET_LINE is followed by a page terminator). To be correct, if a GET_LINE for interactive devices AI-00172/06 2 86-07-23 ra WJ lookahead is pending, LINE and PAGE must wait until the lookahead can be resolved. Thus an operation that does not seemingly need to read from the terminal (i.e., LINE and PAGE) would actually delay a program until it can be determined whether the line terminator is followed by a page terminator. Such behavior would be considered surprising by many users. Another seeming alternative is to use a single ASCII control character (e.g., ) to represent a line terminator followed by a page terminator. Suppose a line terminator is represented by the single ASCII control character, . Then GET_LINE can return immediately after it reads either a or . immediately followed by represents two line terminators followed by a page terminator. The problem with this alternative is insuring the same conventions are followed when outputting text. When NEW_LINE is called, no characters can be output until it is known whether the next call will be to NEW_PAGE. The sequence of calls, NEW_LINE, NEW_PAGE, must output the single control character, , but NEW_LINE followed by PUT must output just . In short, the delays now show up for interactive output rather than interactive input. An alternative that has been considered is to interpret the semantics of NEW_ PAGE so NEW_PAGE always outputs a line terminator followed by a page terminator, even if a NEW_PAGE call is immediately preceded by a call to NEW_ LINE. This interpretation would allow NEW_LINE to always output and NEW_PAGE to always output . Such behavior would not, however, be consistent with the specification in 14.3.4(15), which says (for NEW_PAGE): "Outputs a line terminator if the current line is not terminated or if the current page is empty. Then outputs a page terminator." The recomended solution is to assume page terminators do not exist in the input file. Such an assumption might be made just for files that are associated with interactive terminals. Under this assumption, GET_LINE could return immediately after reading a line terminator, since a page terminator could never be input. The disadvantage of this solution is that GET_LINE must know whether it is being invoked for an "interactive" file. In modern systems, with logical files, virtual terminals, pipes, and networks, it is often impossible to know what ultimate device is associated with an external file. Of course, an implementation could assume that STANDARD_INPUT was "interactive", and otherwise use the FORM argument when OPENing a text file for input to say whether the existence of page terminators should be assumed or not. (The problem would not exist for GET_LINE if GET_LINE called SKIP_LINE before reading characters. This actually was the specification for GET_LINE in the July 1982 Draft of the Ada Standard. The specification was changed to its current form in response to comment #5206, which pointed out that with the 1982 semantics, GET_LINE would skip over an empty line rather than return a value in LAST indicating that the line was empty.)