Re: TEXT_IO anomality

[sampson@cod.NOSC.MIL (Charles H. Sampson)]

In article <9007241309.AA00417@ajpo.sei.cmu.edu|  GDAU100@BGUVM.BITNET ("Jonathan B. Owen") wrote:

||| 2. When doing a Get_line, the user terminates input by pressing <CR| .
|||    This moves the screen cursor to Col 1 of the following line (and
|||    the COL counter of STANDARD_INPUT is updated accordingly).  Still,
|||    the COL counter of STANDARD_OUTPUT remains as before.

In article <2020@cod.NOSC.MIL|  I responded:

|| In a quick skim through the LRM I saw nothing that explicitly required
|| this behaviour.  ...                                       In section
|| 14.3.5 (3) is the statement "All procedures GET and PUT maintain the
|| current column, line, and page numbers of the specified file: ...".  I
|| wonder if implementors have jumped to the conclusion that only these
|| procedures, along with SET_LINE and SET_COL, can affect those numbers?
|| ...                                            In the absence of an
|| explicit requirement to the contrary, I consider this to be a misimple-
|| mentation.  If your cursor is blinking at column 40 and you ask what
|| the column of STANDARD_OUTPUT is, any answer other than 40 is wrong.
|| (Even in the presence of an explicit requirement any answer other than
|| 40 is wrong, but it just might not be possible to fix it.)
                                      
In article <26496@pasteur.Berkeley.EDU|  hilfingr@tully.Berkeley.EDU (Paul Hilfinger) writes:

| Leaving aside the question of whether the behavior is desirable, it is 
| definitely correct.  14.3(6) indicates how terminators may find their way
| into a file; it only mentions operations on the file itself (and "file",
| by the way, always means "internal file" in this chapter, not "external
| file", such as the actual contents of one's screen).  14.3(8) indicates
| that it is these terminators that are counted when determining the value
| of LINE---regardless of any other effects on the external file. 
| 14.3.5(3) indicates that GET, PUT, etc., maintain the column, line, and
| page numbers of the "specified file", and not some other random file
| unmentioned in the statement.  Finally, the Note 14.1(13) indicates that
| the effect of sharing the same "bidirectional" device between several
| file objects is implementation-dependent.

     I agree that the behavior is correct, if you interpret "correct" as
meaning "in conformance with the LRM".  I still think it is wrong, where
by "wrong" I mean "not in conformance with reality".  The question is,
is there another correct implementation that is also "right".  Offhand,
it looks like the note 14.1(13) is a hole big enough for an implementor to
do whatever he wants to do and claim that his implementation conforms.

     Yes, 14.3.5(3) says that the various procedures maintain the various
numbers of the specified file.  But this paragraph does not say that those
numbers cannot be affected by something else, nor does it say that the
listed procedures cannot affect those numbers for a file other than the
specified file.  In other words, it appears that a valid implementation
could say that execution of GET_LINE on STANDARD_INPUT appends a line ter-
minator to STANDARD_OUTPUT and sets the column number of STANDARD_OUTPUT
to 1 (among other things).

     The question of line terminators and line numbers was not brought up
by Mr. Owen, but it is clearly related.  It's probably not as important,
because as long as the terminal is treated as a sequential device the cur-
sor will almost always be on the bottom line of the screen.  (Possible
exception: Has anyone implemented NEW_PAGE(STANDARD_OUTPUT) as meaning
"clear the screen and set the cursor to the upper left corner"?)

     I don't seen how the distinction between "file" and "external file"
has any bearing in the matter.  At the very least, "file" had better have
some relation to "external file".  For example, if someone writes

                      PUT(MY_FILE, "abc");

and causes this statement to be executed, he probably expects to see
"abc" in his external file.  I don't think he would be impressed by the
argument "The string "abc" went to the file object, but we chose not to
write it to the corresponding external file", even if his compiler is
validated.

| Furthermore, I think that changing the behavior of TEXT_IO to take
| account of interactions between input and output on a terminal would be a very
| bad idea.  It would mean, one presumes, that the runtime system would have
| to maintain implicit links between files that read and write from 
| terminals; that every write to a terminal would involve first checking
| for input from the terminal (so as to get the correct final values for
| LINE and COL); and a few other implications I have undoubtably missed.

     An implementation that looks promising and easy is to have the file
control block (or whatever the implementation calls it) point to a block
that contains the three numbers and any other data that might be affected
by the interplay between the two files.  An action on either would then be
immediately available for the other.  Of course, asynchronous access to
either file would cause problems, but asynchronous access to the terminal
is already known to be something that must be handled carefully.

                               Charlie Sampson