JOR Items on Minor I/O Enhancements

                 by Craig T. Dedo
                  April 26, 1996

  This report contains proposals for minor technical enhancements in the
area of I/O.  I presented most of these ideas in e-mail to X3J3 on November 17,
1994 and November 30, 1994.  I am resubmitting these ideas now so that they
are eligible for inclusion in Fortran 2000.

  I am recommending them mostly for reasons of programming effectiveness.
I believe that Fortran should, to the greatest extent possible, be internally
consistent and simple to use.  Fortran should not have the sort of
irregularities, common in other languages, which are usually known only to
the well initiated.  Such irregularities are traps and "gotcha"s that make life
needlessly difficult for the application programmers, who are our customers.

<FORTREQ>
<NUMBER>
<TITLE>        Use of the SIZE= Keyword
<KEYWORDS>
<STATUS>    Registered
<TARGET>
<SUBGROUP>
<VERSION>   1

<REQUIREMENT>
  Allow the use of the SIZE= specifier for both advancing and non-advancing
I/O.
</REQUIREMENT>

<JUSTIFICATION>
  Fortran 90 allows the use of the SIZE= specifier only for non-advancing
I/O.  Informal conversations at X3J3 meetings in 1994 suggested that the
developers of the Fortran 90 standard thought that it would be useful mainly
for non-advancing I/O.  This is unduly restrictive; users should be able to use
the SIZE= specifier both in advancing and non-advancing I/O.
</JUSTIFICATION>

<SUGGESTED IMPLEMENTATION>
  This could be accomplished by making minor edits to sections 9.2.1.3.1,
9.4.1, and 9.4.1.9.
</SUGGESTED IMPLEMENTATION>

<ESTIMATED IMPACT>
  Minimal.  Many Fortran compilers already have some other method for
obtaining the size of the record when using advancing I/O.
</ESTIMATED IMPACT>

<SUBMITTED BY>
  Craig T. Dedo
  Elmbrook Computer Services
  17130 W. Burleigh Place
  Brookfield, WI   53005
  (414) 783-5869
  E-mail: Craig.Dedo@mixcom.com
</SUBMITTED BY>

<REFERENCE>
  X3J3 / 96-007r0 9.2.1.3.1, 9.4.1, 9.4.1.9
</REFERENCE>

<HISTORY>
<EVENT>     May 1996, meeting 137: submitted 96-073
</HISTORY>
</FORTREQ>
**********************************************************************************************
<FORTREQ>
<NUMBER>
<TITLE>        Internal File Data Type
<KEYWORDS>
<STATUS>    Registered
<TARGET>
<SUBGROUP>
<VERSION>   1

<REQUIREMENT>
  Allow the data objects of any KIND of CHARACTER data type that is
defined on the processor to be used as internal files.
</REQUIREMENT>

<JUSTIFICATION>
  Fortran 90 requires that internal files must be of default CHARACTER
type.  This is an unnecessary restriction.  In the next 10-12 years (i.e., the
expected useful life of the Fortran 2000 standard), I expect that the use of
multi-byte character sets such as Unicode (a.k.a. ISO 10646) will grow to be
of substantial importance in character manipulation.  Fortran should
anticipate this development and be prepared to handle it.  In addition, not
allowing all KINDs of character variables as internal files creates an
irregularity.
</JUSTIFICATION>

<SUGGESTED IMPLEMENTATION>
  This could be accomplished by making minor edits to sections 9.2.2.1, 9.3,
and 9.4.2.
</SUGGESTED IMPLEMENTATION>

<ESTIMATED IMPACT>
  Minimal.  Any Fortran processor which supports different KINDs of
CHARACTER data types already has to deal with issues such as
representation and translation.
</ESTIMATED IMPACT>

<SUBMITTED BY>
  Craig T. Dedo
  Elmbrook Computer Services
  17130 W. Burleigh Place
  Brookfield, WI   53005
  (414) 783-5869
  E-mail: Craig.Dedo@mixcom.com
</SUBMITTED BY>

<REFERENCE>
  X3J3 / 96-007r0 9.2.2.1, 9.3, 9.4.2
</REFERENCE>

<HISTORY>
<EVENT>     May 1996, meeting 137: submitted 96-073
</HISTORY>
</FORTREQ>
**********************************************************************************************
<FORTREQ>
<NUMBER>
<TITLE>        Internal Files and List-Directed Formatting
<KEYWORDS>
<STATUS>    Registered
<TARGET>
<SUBGROUP>
<VERSION>   1

<REQUIREMENT>
  Add a note to the standard which explicitly states that starting with
Fortran 90, it is permitted to do list-directed I/O on internal files.
</REQUIREMENT>

<JUSTIFICATION>
  A frequently asked question about Fortran 90 is whether it is permitted
to perform list-directed I/O on internal files.  FORTRAN 77 did not permit this
practice, but Fortran 90 removed this restriction.  Unfortunately, the frequency
of the question indicates that many users still doubt whether this is permitted.
A note in the standard should make this point clear.
</JUSTIFICATION>

<SUGGESTED IMPLEMENTATION>
  Create a note at the end of section 9.2.2.2 which would read something
along the lines of, "Starting with Fortran 90, it is permissible to perform list-directed I/O on internal files."
</SUGGESTED IMPLEMENTATION>

<ESTIMATED IMPACT>
  None.  This is mostly an editorial matter.  Some vendors may wish to
change their documentation.
</ESTIMATED IMPACT>

<SUBMITTED BY>
  Craig T. Dedo
  Elmbrook Computer Services
  17130 W. Burleigh Place
  Brookfield, WI   53005
  (414) 783-5869
  E-mail: Craig.Dedo@mixcom.com
</SUBMITTED BY>

<REFERENCE>
  X3J3 / 96-007r0 9.2.2.2
</REFERENCE>

<HISTORY>
<EVENT>     May 1996, meeting 137: submitted 96-073
</HISTORY>
</FORTREQ>
**********************************************************************************************
<FORTREQ>
<NUMBER>
<TITLE>        Named Scratch Files
<KEYWORDS>
<STATUS>    Registered
<TARGET>
<SUBGROUP>
<VERSION>   1

<REQUIREMENT>
  Allow the user to specify a file name if a file is opened with
STATUS="SCRATCH".
</REQUIREMENT>

<JUSTIFICATION>
  Fortran 90 does not allow the user to name scratch files.  We should lift
this restriction.  Allowing the programmer to name scratch files can be useful,
especially if the program crashes.  Not allowing the programmer to name a file
in this one case is an unnecessary irregularity.  Since there is legacy code
which has STATUS="SCRATCH" without a FILE= specifier, the best solution
is to allow the optional use of FILE= with STATUS="SCRATCH".
</JUSTIFICATION>

<SUGGESTED IMPLEMENTATION>
  This could be accomplished by making minor changes to section  9.3.4.
</SUGGESTED IMPLEMENTATION>

<ESTIMATED IMPACT>
  Minimal.  Adding this capability should not be very difficult to implement.
</ESTIMATED IMPACT>

<SUBMITTED BY>
  Craig T. Dedo
  Elmbrook Computer Services
  17130 W. Burleigh Place
  Brookfield, WI   53005
  (414) 783-5869
  E-mail: Craig.Dedo@mixcom.com
</SUBMITTED BY>

<REFERENCE>
  X3J3 / 96-007r0 9.2.2.2
</REFERENCE>

<HISTORY>
<EVENT>     May 1996, meeting 137: submitted 96-073
</HISTORY>
</FORTREQ>
**********************************************************************************************
<FORTREQ>
<NUMBER>
<TITLE>        Behavior of OPEN with STATUS="UNKNOWN"
<KEYWORDS>
<STATUS>    Registered
<TARGET>
<SUBGROUP>
<VERSION>   1

<REQUIREMENT>
  If the OPEN statement specifies that a file is opened with
STATUS="UNKNOWN", the standard should specify that if the file exists, it
is opened as if STATUS="OLD", and if the file does not exists, it is opened as
if STATUS="NEW".
</REQUIREMENT>

<JUSTIFICATION>
  Fortran 90 and 95 leave this behavior as processor dependent.  This
definition interferes with portability.  It also requires the user to anticipate the
processor's behavior instead of relying on a known, standard behavior.  This
is an unnecessary irregularity.  The recommended change to the standard
behavior is already a popular implementation of OPEN with
STATUS="UNKNOWN".  The DEC (VMS, Unix, and NT), IBM AIX, and Lahey
Fortran compilers already use this implementation.
</JUSTIFICATION>

<SUGGESTED IMPLEMENTATION>
  This could be accomplished by making minor changes to section  9.3.4.2.
</SUGGESTED IMPLEMENTATION>

<ESTIMATED IMPACT>
  This change should not pose any serious implementation problems.  I
expect that the instances of actual incompatibility will be few.  Programmers
should be able to easily resolve any such conflicts.  Implementors should be
able to easily and inexpensively change their implementations to conform to
the new rule, which is equivalent to the following code:
CHARACTER (LEN=250) ::   FILENAME
INTEGER   ::   LUN
LOGICAL   ::   LEXIST
! Define the values of LUN and FILENAME somewhere prior to opening the
file.
INQUIRE (FILE=FILENAME, EXIST=LEXIST)
IF (LEXIST)  THEN
  OPEN (LUN, FILE=FILENAME, STATUS="OLD")
ELSE
  OPEN (LUN, FILE=FILENAME, STATUS="NEW")
END IF
</ESTIMATED IMPACT>

<SUBMITTED BY>
  Craig T. Dedo
  Elmbrook Computer Services
  17130 W. Burleigh Place
  Brookfield, WI   53005
  (414) 783-5869
  E-mail: Craig.Dedo@mixcom.com
</SUBMITTED BY>

<REFERENCE>
  X3J3 / 96-007r0 9.3.4.2
</REFERENCE>

<HISTORY>
<EVENT>     May 1996, meeting 137: submitted 96-073
</HISTORY>
</FORTREQ>
**********************************************************************************************
<FORTREQ>
<NUMBER>
<TITLE>        Action of STATUS="REPLACE" with Multiple Version Files
<KEYWORDS>
<STATUS>    Registered
<TARGET>
<SUBGROUP>
<VERSION>   1

<REQUIREMENT>
  If an operating system or file system supports files with multiple version
numbers, opening a file with STATUS="REPLACE" should create a new file
with the next available version number or version designator.
</REQUIREMENT>

<JUSTIFICATION>
  The standard is silent on what should happen if a file is opened with
STATUS="REPLACE" and the operating system or a file system supported by
the operating system supports multiple version files.  Currently, the Fortran
95 DIS says, "If REPLACE is specified and the files does exist, the file is
deleted, a new file is created with the same name, and the status is changed
to old."  This appears to imply that on a system that supports multiple
versions of files, the old version should be deleted and an empty file with the
same version number created in its place.  However, close consideration of the
text does not make it clear whether:
  (1) the old version should be deleted or,
  (2) a new file created with the next available version designator.

  Here is an example.  There is an existing file COMPLEX_FILE.DAT;3,
where the number following the semicolon is the version designator.  A Fortran
program opens the file using STATUS="REPLACE".  Does the Fortran
program delete COMPLEX_FILE.DAT;3 and re-create it as empty?  Or, does
the Fortran program create a new version, e.g., COMPLEX_FILE.DAT;4?

  I believe that the more useful choice is to create a new file with the next
available version designator.  Choosing this option would preserve the purpose
of multiple versions of files, i.e., to make it easier for users of all kinds to
recover from disastrous mistakes.

  For reasons of clarity, regularity, and portability, we should rule on this
issue rather than leaving it as processor dependent.

  Some may argue that few operating systems or file systems offer multiple
versions of files right now and therefore this issue is irrelevant for the vast
majority of Fortran programmers.  While multiple version file systems may be
few, this feature of a file system may greatly increase in popularity during the
life of the Fortran 2000 standard., which may be as late as 2012.  Therefore,
the issue may be very relevant for a significant fraction of Fortran
programmers during the life of the Fortran 2000 standard.
</JUSTIFICATION>

<SUGGESTED IMPLEMENTATION>
  This could be accomplished by making minor changes to section  9.3.4.2.
</SUGGESTED IMPLEMENTATION>

<ESTIMATED IMPACT>
  Minimal.  Adding this capability should not be very difficult to implement.
</ESTIMATED IMPACT>

<SUBMITTED BY>
  Craig T. Dedo
  Elmbrook Computer Services
  17130 W. Burleigh Place
  Brookfield, WI   53005
  (414) 783-5869
  E-mail: Craig.Dedo@mixcom.com
</SUBMITTED BY>

<REFERENCE>
  X3J3 / 96-007r0 9.3.4.2
</REFERENCE>

<HISTORY>
<EVENT>     May 1996, meeting 137: submitted 96-073
</HISTORY>
</FORTREQ>
**********************************************************************************************
<FORTREQ>
<NUMBER>
<TITLE>        BACKSPACE with List-Directed and Namelist Formats
<KEYWORDS>
<STATUS>    Registered
<TARGET>
<SUBGROUP>
<VERSION>   1

<REQUIREMENT>
  Remove the restriction which prohibits backspacing over records written
using list-directed and namelist formatting.
</REQUIREMENT>

<JUSTIFICATION>
  There appears to be very little, if any, difference between records written
using formatted I/O and those using list-directed or namelist I/O.  Therefore,
this appears to be an unnecessary restriction.  Fortran 2000 should remove
this restriction.
</JUSTIFICATION>

<SUGGESTED IMPLEMENTATION>
  This could be accomplished by making minor changes to section 9.5.1
</SUGGESTED IMPLEMENTATION>

<ESTIMATED IMPACT>
  Minimal.  Adding this capability should not be very difficult to implement.
</ESTIMATED IMPACT>

<SUBMITTED BY>
  Craig T. Dedo
  Elmbrook Computer Services
  17130 W. Burleigh Place
  Brookfield, WI   53005
  (414) 783-5869
  E-mail: Craig.Dedo@mixcom.com
</SUBMITTED BY>

<REFERENCE>
  X3J3 / 96-007r0 9.5.1
</REFERENCE>

<HISTORY>
<EVENT>     May 1996, meeting 137: submitted 96-073
</HISTORY>
</FORTREQ>
**********************************************************************************************
<FORTREQ>
<NUMBER>
<TITLE>        NEXTREC= Specifier in the INQUIRE Statement
<KEYWORDS>
<STATUS>    Registered
<TARGET>
<SUBGROUP>
<VERSION>   1

<REQUIREMENT>
  Fortran 2000 should allow the use of the NEXTREC= specifier for both
direct access and sequential access files.
</REQUIREMENT>

<JUSTIFICATION>
  The Fortran 95 DIS only allows the use of the NEXTREC= specifier only
for direct access files.  This is an unnecessary irregularity.
</JUSTIFICATION>

<SUGGESTED IMPLEMENTATION>
  This could be accomplished by making minor changes to section 9.6.1.14
</SUGGESTED IMPLEMENTATION>

<ESTIMATED IMPACT>
  Minimal.  Adding this capability should not be very difficult to implement.
</ESTIMATED IMPACT>

<SUBMITTED BY>
  Craig T. Dedo
  Elmbrook Computer Services
  17130 W. Burleigh Place
  Brookfield, WI   53005
  (414) 783-5869
  E-mail: Craig.Dedo@mixcom.com
</SUBMITTED BY>

<REFERENCE>
  X3J3 / 96-007r0 9.6.1.14
</REFERENCE>

<HISTORY>
<EVENT>     May 1996, meeting 137: submitted 96-073
</HISTORY>
</FORTREQ>
**********************************************************************************************
<FORTREQ>
<NUMBER>
<TITLE>        ADVANCE="NO" Specifier and Prompting
<KEYWORDS>
<STATUS>    Registered
<TARGET>
<SUBGROUP>
<VERSION>   1

<REQUIREMENT>
  Fortran 2000 should guarantee that the use of the ADVANCE="NO"
specifier in I/O statements can be used by programmers to implement a
genuine prompting capability.
</REQUIREMENT>

<JUSTIFICATION>
  Interpretations of the Fortran 90 standard indicate that the of the
ADVANCE="NO" specifier in I/O statements does not guarantee that
programmers can use a combination of such I/O statements in order to
implement a genuine prompting capability.

  It is my belief that most users expect ADVANCE="NO" I/O statements to
provide a prompting capability.  This difference creates a gap between what
users expect and what the current standard actually provides.  The existence
of this gap contributes to the image that Fortran has of being a "Stone Age"
relic.  This situation should be corrected.

  Although the growing popularity of windowing systems reduces the
severity of this gap, I expect that a need for a genuine prompting capability
will exist for the life of Fortran 2000.
</JUSTIFICATION>

<SUGGESTED IMPLEMENTATION>
  This could be accomplished by making minor changes to sections 9.2.1.3.1
and 9.4.1.8.
</SUGGESTED IMPLEMENTATION>

<ESTIMATED IMPACT>
  Minimal.  Adding this capability should not be very difficult to implement.
</ESTIMATED IMPACT>

<SUBMITTED BY>
  Craig T. Dedo
  Elmbrook Computer Services
  17130 W. Burleigh Place
  Brookfield, WI   53005
  (414) 783-5869
  E-mail: Craig.Dedo@mixcom.com
</SUBMITTED BY>

<REFERENCE>
  X3J3 / 96-007r0 9.2.1.3.1, 9.4.1.8
</REFERENCE>

<HISTORY>
<EVENT>     May 1996, meeting 137: submitted 96-073
</HISTORY>
</FORTREQ>
**********************************************************************************************
<FORTREQ>
<NUMBER>
<TITLE>        Editorial Changes for Chapter 9
<KEYWORDS>
<STATUS>    Registered
<TARGET>
<SUBGROUP>
<VERSION>   1

<REQUIREMENT>
  Fortran 2000 should include any of the editorial changes to Chapter 9 that
I recommended in my paper 94-375 at the November of 1994 meeting of X3J3,
and which did not make it into Fortran 95.  Many of these changes were not
included in Fortran 95 due to the heavy schedule of other editorial work that
had to be done in order to keep Fortran 95 on schedule.
</REQUIREMENT>

<JUSTIFICATION>
  I recommended these editorial changes in order to make Chapter 9 a much
more coherent and well organized part of the document.  Making these changes
would make Chapter 9 much more readable and easier to use.
</JUSTIFICATION>

<SUGGESTED IMPLEMENTATION>
  This could be accomplished by making the recommended changes
throughout Chapter 9.
</SUGGESTED IMPLEMENTATION>

<ESTIMATED IMPACT>
  There would be no impact on the technical content of Fortran 2000.  There
could be moderate to extensive editorial work required.  X3J3 should ask the
Fortran 2000 Project Editor to provide an estimate of the impact.

  Since some of the recommendations reorganize subsections of Chapter 9,
it would be necessary to check other parts of the document to see if cross-references to the reorganized parts need to be changed.
</ESTIMATED IMPACT>

<SUBMITTED BY>
  Craig T. Dedo
  Elmbrook Computer Services
  17130 W. Burleigh Place
  Brookfield, WI   53005
  (414) 783-5869
  E-mail: Craig.Dedo@mixcom.com
</SUBMITTED BY>

<REFERENCE>
  X3J3 / 94-375, "Editorial Changes for 007r3 Chapter 9"
</REFERENCE>

<HISTORY>
<EVENT>     May 1996, meeting 137: submitted 96-073
</HISTORY>
</FORTREQ>

[End of 96-073]