TEXT_IO anomality

TEXT_IO anomality

["Jonathan B. Owen"]

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.
______________________________________________________________________________

Re: TEXT_IO anomality

[Charles H. Sampson]

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

Re: TEXT_IO anomality

[Paul Hilfinger]

|>
|>>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

Re: TEXT_IO anomality

[Vinod Grover]

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

Re: TEXT_IO anomality

[Danford Lehman]

   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
---------------------------------------------------------------------- *

Re: TEXT_IO anomality

[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

Re: TEXT_IO anomality

[Mike Harrison]

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;

TEXT_IO anomality

["", Mats Weber]

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