Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!gatech!psuvax1!schwartz From: schwartz@shire.cs.psu.edu (Scott Schwartz) Newsgroups: comp.lang.pascal Subject: file windows (was Re: Standard Pascal) Message-ID: Date: 12 Jul 89 06:33:01 GMT References: <8616@pyr.gatech.EDU> <18965@paris.ics.uci.edu> <19438@paris.ics.uci.edu> Sender: news@psuvax1.cs.psu.edu Organization: Pennsylvania State University, computer science Lines: 100 Alastair Milne writes: | > while (input^ in [space, tab, newline, cr, formfeed]) do | > get (input) | | How does this constitute not commiting to read the file variable? You are | doing exactly that when you dereference the file variable to get its | window. I didn't say you don't commit to reading the the window variable. The thing you don't commit to is advancing the file pointer: commiting to read from the FILE. | I don't see how this differs at all from | repeat | read( input, ch); | until not (ch in [space, tab, newline, cr, formfeed]); | except that you first copy what would have been the file variable | reference into another variable. Right! In particular, I use the file variable to decide _not to do_ the read. Thus: while (input^ in [...]) do read (input, ch); (* ignore ch *) Is fine, but you have to use while, not repeat, since you have to check the file window first. If you don't, then the last read in your loop eats up and discards one of the valid inputs you are waiting for. (I hope it is clear that I interpreted the question "is get better than read" to mean "read-sans-file-window", since that's what Borland implemented. If you have file windows and get and put, read and write are just syntatic sugar; although the reverse isn't true.) I don't claim you should never use "read"/"write", just that you shouldn't always (have to) use them. Just to make this concrete, assume the above code were wrapped in a procedure, like this: procedure skipwhite; begin << code as above >> end; then you could do the following: ... writeln ('I have declared Russia illegal. Begin bombing? '); skipwhite; read (ch); if (ch in ['n', 'N']) then safe else sorry; ... Now, if we use my code, and type "No" to the prompt everything is fine. If we the code you gave above, then the read will return 'o' instead of 'N', with dire consequences. Having "skipwhite" return the last char it sees doesn't work either, since you could be looking for a number to read next. | >This works without side effects, so that it can be bundled up in a | >black box and called by anyone. | I/O almost always has side effects, because there's almost always | something that can go wrong. [ discussion of error conditions deleted ] Ok, granted that pascal has poor I/O error handling semantics. That wasn't quite the issue. | To the extent, however, that your while loop is free of side effects, and | can be called as a module, so is and can the repeat. No, your loop had different semantics than mine. [ more deleted ] | >I would say a lot harder. ....This requres | >checking all calls to read and write to make sure they read from your | >pushed-back data if it is available. | | Again, I'm not following: I see no pushed-back data in the loop you gave. The file variable handles this. That's the point: I don't have to handle it. | The series of get's the while does is exactly equivalent to the series of | read(ch)'s in the repeat I added. In fact, if the correct definition of | read is used, they must be, because the read is simply "ch := input^; get | (input);" Except for the last "read", whose corresponding "get" never happens because the current character is not whitespace. [ deletions ] | Anybody else like to see UNIX translated to Pascal? I must admit it's | been a pet dream of mine for quite some time. Someone once told me that Apollo's Aegis was mostly written in Pascal. -- Scott Schwartz