[J3] Interaction between user-defined input and list-directed input

[Thomas König]

Hi Malcolm,

 >> My guess, based on the standard's statement that end of record are 
to be treated as blanks in list-directed I/O, is that the second variant 
is a compiler bug, but I am not sure.  Or is this left to the 
implementation?

 > It is arguable that the first variant is a compiler bug, as the 
list-directed READ has no data items before the defined i/o item, so it 
should leave positioning up to the procedure.

 > It's also arguable that the compiler should position to the first 
non-blank, to satisfy the rules about skipping leading blanks. I don't 
agree - I think the standard says the file position is unchanged on 
invocation of the subroutine.

I have not even found a portable way to skip leading blanks and
end-of-records.

 > There is a third variant, where the program aborts saying that the 
defined i/o procedure returned EOR during read. I don't think it should, 
as list-directed*should*  treat an EOR return the same as "we got a 
blank", but the standard does not establish that clearly. So that too is 
arguable.
If any of these variants can be argued, it certainly leaves a lot to the
processor, and what they do differs significantly.  It seams that
this is poorly defined, and would need some elaboration in a
future revision of the standard.

 > Anyway, the "eor are treated as blanks in list-directed" statement 
only applies to i/o performed by the parent i/o statement, not the child 
i/o statement (unless the child also does list-directed).

Another thing that is not made clear, at least as I have been able to
determine.

 > For list-directed defined i/o of a derived type, there is no point in 
duplicating what ordinary list-directed i/o does. IMO it should be doing 
something different, e.g. for this type it should establish that the i/o 
form is e.g. T#xx# (T being the name of the type, # to make it obvious 
that "normal" i/o is not going on here). Then the input read can just 
skip blanks (and EOR) until it finds the EOF (return EOF) or nonblank; 
if it's not "T", it should make up its own error return (good luck 
finding an iostat code that's not in use!), and if it is well then it 
can read the thing. It is possible (if perhaps tedious) to write usable 
defined-i/o procedures with that kind of design.

Depends of what it is used for.  In this particular case, the use case
is I/O  for numbers, where there is a strong expectation that these
should work as they do for normal numbers.  This goal may be
unattainable given the current state of the standard and of how
processors differ, but it should not be the case (IMHO).

Best regards

     Thomas