GDAU100@BGUVM.BITNET ("Jonathan B. Owen") (07/25/90)
1. When using TEXT_IO procedures and function without a file parameter,
STANDARD_INPUT and STANDARD_OUTPUT are used according to the
type of service (i.e. Get or Put, mainly).
Unlike the clarity of the above defaults, the SET_COL and COL
functions apply both to standard input and output. As far as
I know, these services without a file parameter default to
STANDARD_OUTPUT. Is this mentioned or defined in the LRM?
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. This causes
a difficulty when output relys on first obtaining this value and
using it for printing multiple lines at specific column. Since
first line is printed at column 1 even though counter is not so.
Attempting to do a TEXT_IO.SET_COL( TEXT_IO.COL ) will not work,
since this will have no effect.
Also, if you would like to correct the COL counter of STANDARD_OUTPUT
by doing SET_COL(1), so it will be in accord to the screen cursor,
you will result with a blank line (assuming that the counter was
greater than 1).
Here's a demonstrations of the problem:
Put("Prompt> "); Get_line(buffer, last_pos);
declare
c : TEXT_IO.Count := TEXT_IO.COL;
begin
for i in 1..5
loop
-- Adding here Set_col(c) will do nothin in Verdix Ada
-- since delta between c and TEXT_IO.COL is zero!
Put_line("All lines should start from same column!");
TEXT_IO.Set_col(c);
end loop;
end;
Output will look like this:
Prompt> Humph <CR>
All lines should start from same column!
All lines should start from same column!
All lines should start from same column!
All lines should start from same column!
All lines should start from same column!
Any thoughts? Comments? Suggestions?
Jonathan B. Owen
______________________________________________________________________________
(--) /--) /-(\ Email: gdau100@bguvm (bitnet)
\ / /--K | \|/\ /\/) /|-\ Snail: 55 Hovevei Zion
_/_/o /L__)_/o \/\__/ \X/ \_/ | |_/ Tel-Aviv, 63346 ISRAEL
(/ Jonathan B. Owen Voice: (03) 281-422
Point of view: A chicken is the means by which an egg reproduces an egg.
______________________________________________________________________________sampson@cod.NOSC.MIL (Charles H. Sampson) (07/26/90)
In article <9007241309.AA00417@ajpo.sei.cmu.edu> GDAU100@BGUVM.BITNET ("Jonathan B. Owen") writes: > >1. When using TEXT_IO procedures and function without a file parameter, > STANDARD_INPUT and STANDARD_OUTPUT are used according to the > type of service (i.e. Get or Put, mainly). > > Unlike the clarity of the above defaults, the SET_COL and COL > functions apply both to standard input and output. As far as > I know, these services without a file parameter default to > STANDARD_OUTPUT. Is this mentioned or defined in the LRM? Almost. The LRM (14.3.4 (26)) says that the default is CURRENT_OUTPUT. For the uninitiated, CURRENT_OUTPUT is the output file to be used when an output file parameter is omitted in Text_IO. At the beginning of execution CURRENT_OUTPUT is STANDARD_OUTPUT, but CURRENT_OUTPUT can be changed by the procedure SET_OUTPUT. >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. Very interesting. I've verified that VAX Ada behaves the same way. In a quick skim through the LRM I saw nothing that explicitly required this behaviour. (It could be there and I just missed it.) 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 looking at the titles of the 800+ issues considered by the ARG, it appears that this question has never come up. 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.) Charlie Sampson
hilfingr@tully.Berkeley.EDU (Paul Hilfinger) (07/26/90)
|> |>>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. |> |> Very interesting. I've verified that VAX Ada behaves the same way. |>In a quick skim through the LRM I saw nothing that explicitly required |>this behaviour. (It could be there and I just missed it.) 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 looking at the titles of the 800+ issues considered by the ARG, it |>appears that this question has never come up. 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.) |> |> Charlie Sampson 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. 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. Paul N. Hilfinger, (member ARG, URG, and Ada 9X Distinguished Reviewers) Computer Science Division Dept. of Electrical Engineering and Computer Sciences University of California Berkeley, CA 94720 Hilfinger@Berkeley.EDU (415) 642-8401
madmats@elcgl.epfl.ch ("", Mats Weber) (07/26/90)
RFC-822-Headers: Received: from elcgl.epfl.ch by SIC.Epfl.CH with VMSmail ; Thu, 26 Jul 90 15:32:38 N X-ST-Vmsmail-To: gw::"info-ada@ajpo.sei.cmu.edu" gw::"gdau100@bguvm" ================== > Here's a demonstrations of the problem: > > Put("Prompt> "); Get_line(buffer, last_pos); > > declare > c : TEXT_IO.Count := TEXT_IO.COL; > begin > for i in 1..5 > loop > -- Adding here Set_col(c) will do nothin in Verdix Ada > -- since delta between c and TEXT_IO.COL is zero! > > Put_line("All lines should start from same column!"); > TEXT_IO.Set_col(c); > end loop; > end; > > Output will look like this: > > Prompt> Humph <CR> > All lines should start from same column! > All lines should start from same column! > All lines should start from same column! > All lines should start from same column! > All lines should start from same column! > > > Any thoughts? Comments? Suggestions? > > Jonathan B. Owen This behavior is required by the LRM because the page, line and column counts are a property of the internal file object, not the external file (which, in this case, is the terminal). The preceding piece of code actually manipulates two file objects (Current_Output and Current_Input) which are independant from the point of view of the Ada program, but are associated with the same external device (the terminal). As a consequence, reading "Humph" from Current_Input does not change the column count of Current_Output. Note that the language does not even require that Puts to Current_Output and Gets from Current_Input be synchronized, i.e. the string "Prompt> " might not appear before the call to Get_Line. I don't think Text_IO is well suited for reading/writing to or from a terminal. Mats Weber Swiss Federal Institute of Technology EPFL DI LGL 1015 Lausanne Switzerland E-mail : madmats@elcgl.epfl.ch phone : +41 21 693 52 92 fax : +41 21 693 39 09
grover@brahmand.Eng.Sun.COM (Vinod Grover) (07/26/90)
In article <26496@pasteur.Berkeley.EDU> hilfingr@tully.Berkeley.EDU (Paul Hilfinger) writes: > 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. Also, the terminators are not required to be characters or sequences or characters. Furthermore the effect of these terminators on the external files may not be a simple constant function. It could possibly be a function of the state of the (internal) file. I learned this while implementing TEXT_IO on a non-standard operating system. The thing that I find most bewildering about the specification of TEXT_IO is that it does not state that a put followed by a get must yield the same data that was the argument to the put, though ACVCs check for it. Is there a rationale for this or am I missing something? Vinod Grover Sun Microsystems
dlehman@ajpo.sei.cmu.edu (Danford Lehman) (07/28/90)
Norm Cohen has explained why the exception is raised by the assignment
of the record aggregate. The Ada standard makes the point explicit in
paragraph 5.2.1(5):
The implicit subtype conversion described [in 5.2.1(1..4)] for
assignment to an array variable is performed only for the value
of the right-hand side expression as a whole; it is not performed
for subcomponents that are array values.
Dan Lehman Institute for Defense Analyses Alexandria VA USA
---------------------------------------------------------------------- *sampson@cod.NOSC.MIL (Charles H. Sampson) (08/07/90)
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
mph@lion.inmos.co.uk (Mike Harrison) (08/13/90)
In article <2040@cod.NOSC.MIL> sampson@cod.nosc.mil.UUCP (Charles H. Sampson) writes: > ... > >| 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. > I hit the same problem about 3 years ago (in a previous job), the solution we adopted was to define a new i/o package called TERMINAL_IO, whose syntax was a suitable subset of TEXT_IO, but whose semantics implemented the sort of interactions between input and output that you want at a terminal. Unfortunately, the package was implemented by a colleague, so I can't give any details of the internals or any special problems he had to solve. The result was *exactly* what I wanted and avoided compromising the behaviour of our normal TEXT_IO. The TERMINAL_IO package was included in the delivered Ada product. Mike, Michael P. Harrison - Software Group - Inmos Ltd. UK. ----------------------------------------------------------- UK : mph@inmos.co.uk with STANDARD_DISCLAIMERS; US : mph@inmos.com use STANDARD_DISCLAIMERS;