Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!psuvax1!schwartz From: schwartz@shire.cs.psu.edu (Scott Schwartz) Newsgroups: comp.lang.pascal Subject: Re: I/O (was Re: Standard Pascal) Message-ID: Date: 15 Jul 89 03:41:55 GMT References: <20249@adm.BRL.MIL> Sender: news@psuvax1.cs.psu.edu Organization: Pennsylvania State University, computer science Lines: 87 In article <20249@adm.BRL.MIL> Robert Keiser writes: [ A continuing discussion of cyber implementation of pascal. The example in question looks like: PROGRAM TESTIO (INPUT/,OUTPUT); WRITELN('WHAT IS YOUR NAME'); READLN; (* FORCE A GET *) I := 1; WHILE NOT EOLN DO BEGIN READ(NAME I]); I := I + 1; END; ] Robert writes: | 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). I think Robert and I are talking at cross purposes. In his original article he asked how this is done on other systems (VAX, PC). I tried to answer that question. I also offered some explaination about why the implementation he describes for the cyber seems wrong, and wouldn't work as expected on what I consider a correct implementation of PASCAL. | >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? It is part of the runtime system, and effects I/O that goes to terminals. The idea is that while pascal could fill the I/O buffer as soon as a file is opened (initializing the file is like doing a GET to retrieve the first record), it works out better to defer this operation until the file is actually used (via file^ or something) for the first time. Essentially each file operation checks to see if the file has been initialized, and if not, initializes it. | >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. But READLN _discards_ everything up to the end of line, right? If what you want is a GET, do that, not a READLN. I don't see the rationale behind the behavior you describe. | >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. Correct, except we bend the rules when doing lazy I/O to make interactive I/O work as expected. [ ... ] | >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. They are in for a big surprise when the try to use a different implementation. On a Sun, and most other platforms, I would guess, your code yields totally incorrect results. Sounds like cyber has a really strange implementation. [ Robert gives an example of what happens without the slash in the program line ] What happens when you leave in the slash, but delete the READLN? Does EOLN bomb out at that point? What happens when you replace the READLN with a GET (thus making the comments and the code agree!!)? -- Scott Schwartz