clh@tacitus.tfic.bc.ca (Chris Hermansen) (10/17/89)
Perhaps one simple question deserves another...
Does anyone care to offer an explanation/excuse as to why most Pascal
implementors have totally screwed up the I/O? For example, adding the
so-called `interactive' file type, file pointers that become undefined
when there's actually something in the file, etc etc?
The last I recall, a generally acceptable solution to implementing
Pascal I/O was using `lazy I/O', as in:
- reset(f): open the file and set flag indicating f^ needs filling
- get(f): set flag indicating f^ needs filling
- eof(f), eoln(f): fill f^ if necessary, reset flag, and check the condition
- references to f^: fill f^ if necessary, reset flag, and do whatever
So anyway, the beauty of this was supposed to be that segments of code like
var
c1, c2: char;
f: text;
...
reset (f);
write ('Type a character ');
readln(f,c1);
write ('Type another character ');
readln(f,c2);
...
would `work as expected', without any hidden gotchas introduced by an
interactive file type.
I *think* this is the way Sun Pascal does it; T***o certainly doesn't, nor
did Microsoft at the point I tried it (several years ago), nor did the
P-system, nor the 370 Pascal compiler that UBC made while I was a student
there.
Any thoughts?
Chris Hermansen Timberline Forest Inventory Consultants
Voice: 1 604 733 0731 302 - 958 West 8th Avenue
FAX: 1 604 733 0634 Vancouver B.C. CANADA
uunet!ubc-cs!van-bc!tacitus!clh V5Z 1E5reeder@reed.UUCP (Doug Reeder) (10/19/89)
In article <115@tacitus.tfic.bc.ca> clh@tfic.bc.ca (Chris Hermansen) writes: >Does anyone care to offer an explanation/excuse as to why most Pascal >implementors have totally screwed up the I/O? For example, adding the >so-called `interactive' file type, file pointers that become undefined >when there's actually something in the file, etc etc? >The last I recall, a generally acceptable solution to implementing >Pascal I/O was using `lazy I/O', as in: ... My experience writing a Pascal Compiler is that is lazy i/o is a pain to implement, as input must be treated differently than all other files, but not wildly difficult. The compiled code is surprisingly simple. In fact, the Pascal file paradigm, normaly a pain, made eof() amazingly simple. There is really no excuse for compilers not to implement lazy i/o. -- Doug Reeder USENET: ...!tektronix!reed!reeder Box 722 Reed College BITNET: reeder@reed.BITNET Portland, OR 97202 from ARPA: tektronix!reed!reeder@berkeley.EDU (503) 777-1551 "A blaster can point two ways." -Salvor Hardin
diamond@csl.sony.co.jp (Norman Diamond) (10/23/89)
In article <115@tacitus.tfic.bc.ca> clh@tfic.bc.ca (Chris Hermansen) writes: >>The last I recall, a generally acceptable solution to implementing >>Pascal I/O was using `lazy I/O', as in: That is my impression too. In article <13428@reed.UUCP> reeder@reed.UUCP (Doug Reeder) writes: >My experience writing a Pascal Compiler is that is lazy i/o is a pain to >implement, as input must be treated differently than all other files, I think you mean the predefined "input" file. I would think that ALL files opened-for-input could be treated equally lazily, and that special treatment would not be required for the predefined "input" file or for other files associated with interactive devices. >but not wildly difficult. >There is really no excuse for compilers not to implement lazy i/o. True. -- Norman Diamond, Sony Corp. (diamond%ws.sony.junet@uunet.uu.net seems to work) Should the preceding opinions be caught or | James Bond asked his killed, the sender will disavow all knowledge | ATT rep for a source of their activities or whereabouts. | licence to "kill".