Dan Nagle wrote:
>
> Hello,
>
> Richard Maine wrote:
> >
> <snip PROTECTED discussion>
> >
> > > 5. I hope the suggestion for stream IO isn't lost in the
> > > PROTECTED discussion. This is certainly an F2K + 1 issue,
> > > it seems 'too big' for a last-minute inclusion.
> >
> <snip down to bullets>
> >
> > 1. No formatted stream I/O. While perhaps nice, this adds many
> > complications, and is not the most critical need. No, I'm not
> > negotiable on this. I might possibly agree to a proposal that
> > included formatted stream I/O, but I do *NOT* have time to
> > write one (not if its to do a good job).
>
> Agreed. The programmer can always read into a character string,
> and roll-yer-own formatting.
And the non advancing I/O of Fortran 95 is already a good step.
>
> >
> > 2. No random positioning. This would certainly be a desirable
> > feature, but it raises questions that might start enough debate
> > to derail approval. (Namely - do you position by byte-number,
> > word-number, system-dependent units, or possibly only to points
> > returned by some form of inquiry?) I'd rather go without it at
> > first, and consider it as a possible later add-on. Plus, I
> > haven't considered it carefully enough yet myself to be sure of
> > my preferences.
>
> Agreed. If you want to choose a unit, how 'bout the unit used
> by the IOLENGTH specifier? Presumably, that's a unit the processor
> is comfortable with (i.e., no byte addresses on word addressable
> processors, etc.).
>
In fact, this feature could be added very easily:
1- By adding a POS= specifier in READ and WRITE statements such
as: READ(1,POS=position)input_list where position is in a unit that
remain to be determined.
2- By adding a CURRPOS= option in INQUIRE to query about the current
position of the file pointer. Following an OPEN, the position returned
by CURRPOS is 1, if POSITION is anything other than APPEND, and the
size of the file + 1 if POSITION = 'APPEND'.
The only obscure point is the choice of the unit used to address the
file. The unit used by IOLENGTH is an acceptable choice.
> >
> > 3. Syntax basically identical to unformatted sequential I/O (minus things
> > like backspace and anything else that seems incompatable).
>
> Agreed.
>
I consider however that the "binary" WRITE should only overwrite the
portion of the file corresponding to the length of the output list,
in the contrary of an unformatted sequential WRITE. The remaining of the
file should remain unchanged. If the user wants to truncate the rest of
the file, ENDFILE should be used instead. REWIND should also be
allowable.
> >
> > 4. Probably use something like FORM="STREAM" in the OPEN statement;
> > subject to some debate. Its arguable that this might be more
> > like an ACCESS than a FORM, but I lean somewhat towards a FORM. But
> > not a FORM="BINARY"; although there is some precedent, it is way
> > too misleading. Unformatted I/O is binary just as much as this
> > proposed new form.
>
> Again, agreed. This way, no vendor extensions are stepped on.
Possible alternatives are FORM='RAW' or ACCESS='STREAM' (no preference).
I am quite happy that finally someone agreeds to work on this feature.
Regards,
Jean Vezina
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|