Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!sun-barr!ames!haven!adm!xadmx!RDK%vm.temple.edu@cunyvm.cuny.edu
From: RDK%vm.temple.edu@cunyvm.cuny.edu (Robert Keiser)
Newsgroups: comp.lang.pascal
Subject: Re: I/O (was Re: Standard Pascal)
Message-ID: <20249@adm.BRL.MIL>
Date: 14 Jul 89 13:32:10 GMT
Sender: news@adm.BRL.MIL
Lines: 89

On 14 Jul 89 03:15:01 GMT you said:
>
>Robert Keiser writes:
>
>|      WRITELN('WHAT IS YOUR NAME');
>|      READLN; (* FORCE A GET *)
>|      I := 1;
>|      WHILE NOT EOLN DO
>|       BEGIN
>|        READ(NAME[I]);
>|        I := I + 1;
>|      END;
>
>| I mean, it would seem that to follow the way Pascal is supposed to
>| work with the "look ahead" buffer it would require something special
>| to avoid the above example.
>
You left out one important line, the program statement.  I didn't keep what
I wrote but it went something like this:
        PROGRAM TESTIO (INPUT/,OUTPUT);
That slash after the INPUT filename is important.  It tells the compiler not
to put in that initial GET when it generates the code.  Without that READLN
the program won't work (I'm talking about the Cyber implentation).

>A pure implementation of Pascal I/O would have the program block just
>after it began executing while it waited for the INPUT buffer to get
>filled.

Yes except that I told the compiler I was working with an interactive file
(again due to the slash).

>The most common technique for making interactive I/O work sensibly is
>called "lazy I/O", and arranges not to block for input until necessary.

This is the answer to my question, except, how does "lazy I/O" work?  Is it
part of the readln procedure or is it something special?

>In your example, the "READLN (* FORCE A GET *)" doesn't seem to be
>what you really want to do, since it could potentially discard valid
>input in addition to filling the buffer.

No it won't discard valid input because INPUT^ is not set to anything because
of the slash.  Besides, I want to fill the buffer for the next read.

>Beyond that, I would have expected the EOLN to force the (buffer
>filling) GET, since that's when you actually require the data.

The EOLN will only LOOK at INPUT^, it should not try to get any data from the
input buffer.

>Similarly, if you had some thing like "foo := input^" as the first use
>of "input", the buffer would be filled at that point.  (Of course, the
>runtime system should only do the inplicit GET once, to initialize the
>input stream, not each time you do that statement.  Some pascal to C
>translators screw this up.)

Again, "foo := input^" will not fill any buffer (at least it shouldn't, if
it did you wouldn't need GET) it will only assign the value of input^ to foo.

>A quick test with Sun's Pascal compiler shows that omitting the READLN
>results in a working program, as expected.

Again, I did try this on a Cyber and it worked fine.  In fact, this method is
taught to our students as a way to do interactive I/O.

For completness sake the following is what it would look like without that
slash.

?            <- the ? is from the initial GET (on the cyber, if you request
                input from a file that the operating system knows is attached
                to the terminal, it will force the ?.)  At this point I would
                have to enter something but unless I knew what the program was
                going to ask me for I wouldn't know what to enter.  If I press
                the <cr> then this is what would happen
WHAT IS YOUR NAME


  PROGRAM TERMINATED AT LINE # IN PROGRAM TESTIO.
  TRIED TO READ INPUT PAS EOS/EOF.

This would then be followed by the variable values at the time of termination.
If I took out the READLN; I would get the exact same result.

Finally, I would like to thank Steve for his response.  I understand his
misunderstanding (sounds interesting doesn't it :-) about how the Cyber Pascal
work.  He did, however, give me a hint of how this process works on other
systems.  Now Steve, what is "lazy I/O".

Robert Keiser    <rdk@templevm>