When thinking some days about the initial RESET on INPUT applied by the compiler at the beginning of the main program, I came to the conclusion that it would be best not to require a RESET operation at all.
That was inspired in part by the observation that the implicit RESET and REWRITE is done for the standard files (INPUT, OUTPUT, PRR, PRD, QRR and QRD), but not for the additional files appearing on the program statement having arbitrary names (which was introduced with the 1982 McGill version). I didn't see a valid reason for this difference. So I decided in the end, that all RESETs and REWRITEs should be optional, that is: if no RESET has occured before the first READ (or GET) operation, it is done then. Same goes for REWRITE. I don't recall if Pascal VS did it this way, but it seems possible to me.
Of course, it must still be possible to do the RESET and REWRITE explicitly; this should make no difference to an implicit RESET on the first READ call. So the status of the file (if RESET has already been done or still needs to be done) must be recorded somewhere. And: the RESET at a later time, when a file that has been processed already fully or in part is read again from the start by a new RESET operation, must of course be supported in the same way as before. But on the other hand it should be impossible to do a READ after REWRITE or a WRITE after RESET.
To make all this possible, I first had to find some free space in the file control blocks that Pascal builds for every file. I shifted the DCB (which is part of this file control block) 4 bytes to offset 36, so I had room for 4 flags of one byte, of which I used the first (offset 32) to record the file status.
There are 4 status values:
0 = the file is closed
1 = reset has been issued, but no read operation
2 = rewrite has been issued, but no write operation
3 = read operations have been issued
4 = write operations have been issued
and a transtition matrix, which shows, which status changes are applied on which file operation (RESET, READ, REWRITE, WRITE). See the PASMONN.ASS source for details (Resources paragraph below).
Very important: this all applies only to files of type TEXT (FILE OF CHAR); for files of other types (for example FILE OF INTEGER or FILE OF RECORD ...) there are no implicit RESETs and REWRITEs, and the file status is never changed away from 0 for those (binary) files.
When I had applied all those changes to the file handling routines (after running some tests successfully), I could finally drop the implicit RESET on INPUT at the beginning of the main procedure, because the RESET will occur automatically at the first READ or GET.
Now the problems:
The compiler and the P-Code translator refused to work from that moment on, because they tested for EOF (INPUT) before the first READ. And it was FALSE with the prior implementation (because of the initial RESET), but it was TRUE now. The solution was obvious: inserting an explicit RESET (INPUT) at the beginning of each program.
In fact, every program that controls the input loop in the following way, has to be changed (without the RESET, the program will do nothing, because EOF (INPUT) is true at the beginning).
|
But anyway: I decided to stay with this solution, because I didn't see another way of getting rid of the initial terminal input at the implicit RESET. So this is how it works for the moment. Programs that need this type of control (as outlined above) need to do an explicit RESET (INPUT) at the beginning of the main program.