(j3.2006) Partial write in record with nonadvancing I/O

[Malcolm Cohen]

>Assuming the "current record" is the same for reading and writing a
>file, statement 4 then positions the file between the eighth and ninth
>characters of the same first record.

Well, I think it does something more than that - it transfers some data to the 
file.

>Assuming the "current record" is different for reading and writing a
>file,

What nonsense is this?  Look at what file position is about.  There is only one 
file position!  We keep talking about "the file is positioned between ..." which 
does not make sense unless it is unique.

>It is not obvious which assumption to make.

Just try reading 9.3.4.

As for
>  Sequential I/O in Fortran
>was originally based upon tape, where reading a record physically
>positioned the medium between records.  Nonadvancing I/O could, in the
>context of tape, muck with the buffer, but not the physical position of
>the tape.

Nonadvancing i/o did not exist at that time.  And the file position is 
absolutely NOT the physical position of the tape anyway.

>It would be helpful if 9.3.4.2p2 were to specify whether a nonadvancing
>read followed by a write (nonadvancing or not) has the retroactive
>effect of advancing.  By omission, it implies it does not.

No.  By omission it does not reformat your disk drive.  Or deallocate all 
complex allocatable arrays.  Or assign 37 to X.

Oh, and it does not change the file position in any way other than how it says, 
either.

The file position is changed precisely when and where it says in the standard. 
Nothing more.  Nothing less.  There is no ambiguity.

> If it should
>not, a note would be helpful, since to accomplish the feat of not
>implying completion of an advancing read if a nonadvancing read is
>followed by a write, an intervening hidden BACKSPACE is required if the
>physical medium is tape.

The ludicrous idea that we should explain everything as if we were using some 
obsolete hardware from the 1950s is ludicrous.

>Additional assumptions are required:

No they are not.

>  Either the external medium is not tape,

That has nothing to do with anything.

> or if it is the processor is required to insert a hidden BACKSPACE
>between the necessarily advancing read that filled the buffer upon which
>statement 3 operates, and statement 4.

This is mistaking the levels of abstraction.  We do not talk about the physical 
characteristics of storage AT ALL.  That is not in the scope of the standard. 
Moving a piece of tape around is not BACKSPACE.  BACKSPACE is a Fortran 
operation.  However a processor moves the tape around in the process of 
implementing something other than BACKSPACE is not BACKSPACE, it is just the 
physical operation of moving the tape around.

I might point out that on streaming tape drives, the actual tape position can be 
a very very long way indeed from where the logical file position might imply.

>The problem is not resolved
>unless one assumes that "file" is an abstraction that doesn't work as
>some external media would require it to work.

That is simply nonsensical.  A Fortran processor can be a human being with 
pencil and paper, that does not imply that we should explain the consequences of 
having to use an erasor when doing assignment.

A file ***IS*** an abstraction.  There is no mention of extra pieces of paper, 
or the 2-ring binder in which to keep them.

Anyway, you earlier admitted that there was no problem with tape, it just gets 
moved around a lot.  Well big deal - paper gets shuffled a lot too.  Disc drives 
spin round and round, but that doesn't mean we should get dizzy or try to 
describe what they do in terms of hypothetical Fortran statements acting 
directly on the hardware.  There is no hardware that acts precisely like our 
models, there are multiple layers of hard/firm/software on tape/discs/SSDs that 
go into implementing the convenient abstraction that is a file system and files. 
Our model is general enough (and weak enough) to be implementable on a very wide 
range of hardware+software and specific enough to be useful.

>That's certainly true, but not a valid excuse for avoiding improvement
>in exposition.

I am yet to read any suggestion that would be an improvement.  Inserting loads 
of irrelevant guff about hardware that was obsolete back in F77 days would be
(a) completely outside the scope of the standard;
(b) a significant disimprovement;
(c) a total waste of time.

Cheers,
-- 
................................Malcolm Cohen, Nihon NAG, Tokyo.