Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!mcvax!kth!draken!tut!santra!mjolner!tnvsu1!eru From: eru@tnvsu1.tele.nokia.fi (Erkki Ruohtula) Newsgroups: comp.lang.pascal Subject: Re: file windows (was Re: Standard Pascal) Keywords: interactive IO Message-ID: <437@mjolner.tele.nokia.fi> Date: 26 Jul 89 09:56:10 GMT References: <8616@pyr.gatech.EDU> <18965@paris.ics.uci.edu> <4623@freja.diku.dk> Sender: news@mjolner.tele.nokia.fi Reply-To: eru@tnvsu1.UUCP (Erkki Ruohtula) Organization: Nokia Telecommunications Lines: 26 Kristian Damm Jensen (dat0@diku.dk) writes >As somebody already have pointed out, "read(input, ch)" is exactly >equivalent to "ch:=input^;get(input)" (by definition of the ISO standard). > >The interesting thing about this is (IMHO) that using the filewindow you >can check what you are about to read, not just what you have already read. >I have seen a couple of examples, where this saves you a lot of trouble. > ------------------------------- >BTW it is the file-window that allows you to check eoln and eof. How do you >manage to check that, if you don't have some kind of look-ahead? I have seen many examples where it gives you no end of trouble... This file window business is the reason why there is no such thing as a portable interactive Pascal program. I have seen two ways of dealing with it: lazy I/O (do the I/O when the file buffer variable is referenced) and implicitly prepending an Eoln to a text file, thus making it the value of the file buffer variable when the program starts up. An interactive program written for one convention acts strangely when compiled with a compiler using the other convention... No doubt there are other variations around. Having an "unread" operation would be a much better way of dealing with lookahead, because then you get lookahead only when you want it. Maybe this could be added to the rumoured new Pascal standard? Erkki Ruohtula ! Nokia Telecommunications eru@tele.nokia.fi ! P.O. Box 33 SF-02601 Espoo, Finland