Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cornell!uw-beaver!ubc-cs!alberta!uqv-mts!Al_Dunbar
From: userAKDU@ualtamts.BITNET (Al Dunbar)
Newsgroups: comp.lang.fortran
Subject: Was: Re: length of a character string
Message-ID: <2490@ualtamts.BITNET>
Date: 26 Sep 89 14:06:14 GMT
Organization: University of Alberta (MTS)
Lines: 82
Summary: Rationale for "Non-advancing I/O"

Thanks  to  Keith H. Bierman for setting me straight on a number of points
regarding the proposed Fortran 8X standard as it relates to varying length
strings and non-advancing I/O. (I would have posted a followup, but by the
time I was ready, his article was no longer unavailable).
 
I can easily live without  varying  length  character  variables,  as  the
standard provides other facilities that may be used in their place, namely
pointers and modules.
 
Mr. Bierman wrote:
>Mr. Dunbar writes:
>>Rather than putting it directly into the standard at this late
>>date, however, a compromise was reached. The concept of non-
>>advancing I/O was ...
>Has nothing to do with varying length string proposals.
 
If  this  is  indeed  the  situation,  how  do  you  explain the following
paragraph, extracted from ISO/IEC JTC1/SC22/WG5  document  N395,  entitled
"Summary  of Changes to Fortran Draft", in the section entitled "Rationale
for Major Changes to Draft Fortran Standard":
 
>                                INPUT/OUTPUT
>
> 1. Partial Record I/O added
>
> The  international  community  provided  most  of  the public comment on
> character processing, such as described above for Kanji support. Another
> request from this community was for varying character capability. It was
> finally agreed that the best way  to  provide  this  was  as  a  varying
> character   module,   but   that   some   sort   of   stream  I/O  (e.g.
> GETCHAR/PUTCHAR) was needed to do that. As a stream I/O  facility  would
> have  much wider use than just this application, it was decided to add a
> stream I/O capability to Fortran 8X. Initially considered  were  GETCHAR
> and  PUTCHAR intrinsic functions. However, the final decision was to add
> versions of the READ and WRITE statements that work on only part of  the
> current I/O record -- hence, the term partial record I/O.
 
I  apologize  if  I  have  misunderstood, but the above text is the _ONLY_
explanation I have as yet seen for the  appearance  of  Non-advancing  I/O
that  has  _ANY_  official  stamp  on  it. This and the comments of fellow
members  of  CSA/CPL/FWG  who  have  represented  Canada  at  various  WG5
meetings.  It is indeed unfortunate that it is not easier to determine the
actual reasoning that goes into the various decisions made  by  X3J3,  and
further, that this lack of information occasionally suggests (incorrectly,
in most cases I hope) a lack of rigorousness in the proceedings.
 
Mr. Bierman further writes:
>Asynchronous I/O is very hard to specify in a completely OS independent
>fashion. The current proposal should cover character at a time (though
>one expects there to be efficiencies for grabbing more per transaction)
>and asynch extensions are probably planned by most of the vendors whose
>operating systems support such things.
 
True  to  the  first  sentence.  This  may,  however,  be  more  a case of
asynchronous I/O just being new to Fortran,  as  the  X3J11  committee  is
having  no  problems  with  this issue in the C standard. Consider how the
Fortran standard allows for the use of cataloging (i.e. "filenames") while
stating  that  this  capability  is  not  a  requirement of the processor.
Granted,   many   vendors   will   supply   Asynchronous   I/O   features;
unfortunately,  some  via ADVANCE=NO, and some via GETCHAR/PUTCHAR, as the
standard basically says NOTHING about how it could or should be done.  For
example,  if  ADVANCE=NO is used for terminal input, how could the echo be
suppressed?
 
As proposed, Non-advancing I/O (NAI/O)  allows  for  (at  least)  two  new
capabilities  which  I applaud: the reading of *LARGE* records without the
need for a large buffer internal to the program, and the determination  of
actual  record  length.  However,  the  first _can_ be done with a varying
execution time format and a BACKSPACE statement, while the second  _could_
be done by allowing the IOLENGTH= keyword to be applied to READ statements
as well as INQUIRE's. NAI/O does NOT seem to make up for the loss  of  the
PROMPT=  keyword,  as I can find no indication that partial output records
will ever be emitted until the end of record is specified. I find  PROMPT=
to  be  much  simpler  approach  to this, as the program would not have to
determine which unit should be used to issue the prompt or when prompts
should  be  suppressed  because input was coming from a file rather than a
terminal.
-------------------+-------------------------------------------
Alastair Dunbar    | Edmonton: a great place, but...
Edmonton, Alberta  | before Gretzky trade: "City of Champions"
CANADA             | after Gretzky trade: "City of Champignons"
-------------------+-------------------------------------------