JOR Items on Various Subjects

                 by Craig T. Dedo
                  April 26, 1996

  Following is a list of various items that I am proposing for inclusion in the
Journal of Requirements for Fortran 2000.  Admittedly, this paper has the
look-and-feel of the "kitchen sink" approach.  However, I consider each of these
items to have at least some technical merit.  The order of listing does not state
or imply any ranking of importance.  Much of the content proposes a
ratification of existing practice.

  Considering the amount of work that we have to do for Fortran 2000, it
may be impractical or impossible to incorporate even a small fraction of these
items into Fortran 2000.  However, I am proposing these items because I
believe that it is useful to place all good ideas on the table for consideration.
Whether any of these ideas possess sufficient technical merit in order to
qualify for Fortran 2000 should be determined by lucid and clarifying debate.

<FORTREQ>
<NUMBER>
<TITLE>        CPU_TIME Enhancements
<KEYWORDS>
<STATUS>    Registered
<TARGET>
<SUBGROUP>
<VERSION>   1

<REQUIREMENT>
  The CPU_TIME intrinsic subroutine should be extended to include
additional arguments and to make the TIME argument optional.  The
additional arguments would allow for the inquiry and measurement of user
time, system time, and the minimum unit of time in the processor's
measurement system.
</REQUIREMENT>

<JUSTIFICATION>
  It is possible that a precise definition of CPU_TIME will evolve as an ISO
standard in the near future.  This capability would allow the Fortran standard
to anticipate and keep up with any such development.

  If these extensions become part of CPU_TIME, the TIME argument may
not be relevant in all calls to CPU_TIME.
</JUSTIFICATION>

<SUGGESTED IMPLEMENTATION>
  One method would be to use the following interface:
SUBROUTINE CPU_TIME (TIME, USER, SYSTEM, DELTA)
REAL, OPTIONAL, INTENT (OUT) :: TIME    ! Processor time
REAL, OPTIONAL, INTENT (OUT) :: USER    ! User time
REAL, OPTIONAL, INTENT (OUT) :: SYSTEM ! System time
REAL, OPTIONAL, INTENT (OUT) :: DELTA   ! Minimum time increment
</SUGGESTED IMPLEMENTATION>

<ESTIMATED IMPACT>
  This feature would have no impact on existing implementations.  The cost
to vendors to implement this feature should be very low.
</ESTIMATED IMPACT>

<REFERENCE>
  ISO/IEC 1539:1996 (E) 13.14.25 (a.k.a. X3J3/95-007r1)
  X3J3/95-259
  X3J3/95-268
</REFERENCE>

<SUBMITTED BY>
Craig Dedo               On behalf of Jens Bloch Helmers
Elmbrook Computer Services    Det Norske Veritas Research AS
17130 W. Burleigh Place
Brookfield, WI   53005        N-1322 Hoevik
USA                   NORWAY
+1 (414) 783-5869             +47 (67) 57 75 31
E-mail: Craig.Dedo@mixcom.com E-mail: helm@vr.dnv.no
</SUBMITTED BY>

</FORTREQ>
**********************************************************************************************
<FORTREQ>
<NUMBER>
<TITLE>        $ Character in Symbolic Names
<KEYWORDS>
<STATUS>    Registered
<TARGET>
<SUBGROUP>
<VERSION>   1

<REQUIREMENT>
  Fortran 2000 should include the use of $ as a permissible character for
Fortran symbolic names for such things as arrays, variables, COMMON blocks,
modules, etc.
</REQUIREMENT>

<JUSTIFICATION>
  The $ character is a popular extension.  David Levine's survey of
extensions found that it is included in the Cray, DEC, EPC, HP, IBM, and
Lahey compilers.  Names contain the $ character are often used to name many
operating system functions and subroutines.  Including this character in the
standard will make it easier to have Fortran programs use such routines.
</JUSTIFICATION>

<SUGGESTED IMPLEMENTATION>
  Change the list of permissible characters in symbolic names in section 3.1.1
so that $ is in the list.
</SUGGESTED IMPLEMENTATION>

<ESTIMATED IMPACT>
  Minimal.
</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>
  ISO/IEC 1539:1991 (E) 3.1.1
</REFERENCE>

<HISTORY>
<EVENT>     May 1996, meeting 137: submitted 96-074
</HISTORY>
</FORTREQ>
**********************************************************************************************
<FORTREQ>
<NUMBER>
<TITLE>        Standardized Character Sets Including ASCII
<KEYWORDS>
<STATUS>    Registered
<TARGET>
<SUBGROUP>
<VERSION>   1

<REQUIREMENT>
  Fortran 2000 should require a compiler to provide full support for the 7-bit
ASCII character set.   This would be the ANSI definition, WITHOUT the
National character Set Options.  This would mean that 7-bit ASCII would be
a required KIND on a standard conforming compiler.  It would not be
necessary for a processor to offer 7-bit ASCII as the default character set or as
the KIND type for Fortran source statements.  However, a processor would be
required to include in the Fortran character set all of the characters in
positions 32 - 126 in the ASCII table.

  In addition, Fortran 2000 should require support of the ASCII character
set interpreted according to the latest ISO C language standard.  This C
language character set would have its own unique KIND number.

  As an extension of this requirement, the standard could also require
support for the ISO Latin-1 character set and possibly other ISO character
sets.

  Development of this requirement should follow the recommendations of the
ISO TR 10176, Guidelines for the Preparation of Programming Language
Standards.
</REQUIREMENT>

<JUSTIFICATION>
  This requirement would greatly increase portability of code, both from one
platform to another and from one country to another.  Although workarounds
exist, they usually are difficult and costly to use.  The time and effort of
application developers should be spent solving their problems rather than
fighting the limitations of the programming language.

  The increasing use of multiple platforms for software development and the
increasingly international character of general business and trade over time
means that this functionality gets more desirable each year.  Use of a wider
variety of characters in ordinary printed materials is becoming far more
widespread than previously.  This means that the kluges of the past are
becoming untenable.  It also means that portability is becoming far more
important than it used to be.

  If this issue is ignored, it will become increasingly difficult and costly to
engage in workarounds.

  I do not believe that standards bodies can ignore any longer the need for
some standardized character sets in programming languages.  The earlier such
fundamental issues are standardized, the less costly and difficult
implementation will be.
</JUSTIFICATION>

<SUGGESTED IMPLEMENTATION>
  The language of sections 3.1 and 4.3.2.1 can be modified to require support
of the selected ISO character sets.  This should be quite simple by making
reference to the necessary ISO standards.
</SUGGESTED IMPLEMENTATION>

<ESTIMATED IMPACT>
  This would require vendors to support several additional KINDs for
CHARACTER data types.  It should not be very difficult or costly for vendors
to implement this requirement.  Some changes may be required to compilers
in the case of vendors who support ASCII according to the C language
conventions.

  This requirement may involve considerable debate in the standards making
process in order to make a high quality selection of required character sets.
</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>
  ISO/IEC 1539:1991 (E) 3.1, 4.3.2.1
</REFERENCE>

<HISTORY>
<EVENT>     May 1996, meeting 137: submitted 96-074
</HISTORY>
</FORTREQ>
**********************************************************************************************
<FORTREQ>
<NUMBER>
<TITLE>        TAB Character in Fortran Source
<KEYWORDS>
<STATUS>    Registered
<TARGET>
<SUBGROUP>
<VERSION>   1

<REQUIREMENT>
  Fortran 2000 should allow the use of TAB characters in free source form.
The TAB character should be interpreted as if it was one blank character.
</REQUIREMENT>

<JUSTIFICATION>
  This is a popular extension and often makes the source code easier to read.
Several vendors, including Cray, DEC, EPC, HP, IBM, and Lahey support this
feature.
</JUSTIFICATION>

<SUGGESTED IMPLEMENTATION>
  Add TAB to the list of characters in the Fortran character set.  Write a
rule requiring that TAB be treated the same as space.
</SUGGESTED IMPLEMENTATION>

<ESTIMATED IMPACT>
  Minimal.
</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>
  ISO/IEC 1539:1991 (E) 3.1
</REFERENCE>

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

<REQUIREMENT>
  Fortran 2000 should include support for the BYTE data type, defined an
a sequence of 8 bits. The BYTE data type could be used for very small signed
or unsigned integers, for bit masks, and for 8 bit characters.  It could be the
TARGET of a POINTER assignment and used in building derived types.  It
could be storage associated with any other data type using the
EQUIVALENCE statement.  Any kind of data should be able to be assigned
to a BYTE data type or a BYTE array.
</REQUIREMENT>

<JUSTIFICATION>
  The BYTE data type is very useful for building data structures used to
access operating system data structures.  It also could be used for building
various derived types that either are cumbersome or impossible to build using
the currently available data types.  BYTE arrays can also be used for various
types of low level data manipulation which is difficult to do using the current
data types.  The implementation of the BYTE data type in compilers from
Cray, DEC, EPC, HP, IBM, Lahey, and Sun attests to the popularity and
usefulness of the BYTE data type.
</JUSTIFICATION>

<SUGGESTED IMPLEMENTATION>
  This feature should be implemented in the same manner as the BYTE data
type is implemented in the compilers mentioned above.  The syntax should
follow the model used for current intrinsic data types.
</SUGGESTED IMPLEMENTATION>

<ESTIMATED IMPACT>
  There should be little impact to current processors.  Vendors who do not
support BYTE should find this easy 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>
  ISO/IEC 1539:1991 (E) 4.3.2, 5.1, 5.1.1
</REFERENCE>

<HISTORY>
<EVENT>     May 1996, meeting 137: submitted 96-074
</HISTORY>
</FORTREQ>
**********************************************************************************************
<FORTREQ>
<NUMBER>
<TITLE>        Automatic or Dynamic Data Objects
<KEYWORDS>
<STATUS>    Registered
<TARGET>
<SUBGROUP>
<VERSION>   1

<REQUIREMENT>
  Fortran 2000 should provide a means of declaring that data objects
definitely disappear when they go out of scope.
</REQUIREMENT>

<JUSTIFICATION>
  In the Fortran 90 standard and the Fortran 95 DIS, it is processor
dependent what happens to data objects if they do not have the SAVE
attribute.  Some processors make all data objects static while others make non-SAVE data objects dynamic (a.k.a. automatic).  There should be a way for an
application developer to declare that a data object definitely disappears when
it goes out of scope.  This would give the application developer more control on
exactly how data objects are declared and used.  Most other popular languages
have this capability.
</JUSTIFICATION>

<SUGGESTED IMPLEMENTATION>
  This feature could be implemented by defining another data object
attribute (5.1.2) and statement (5.2).  Probably the best keywords would be
either DYNAMIC or AUTOMATIC.  The EPC, HP, IBM, and Sun Fortran
compilers use the AUTOMATIC keyword as an extension to Fortran.
</SUGGESTED IMPLEMENTATION>

<ESTIMATED IMPACT>
  This feature should not cost a great deal to implement.  Since its
equivalent appears in most other languages and this feature is already an
extension to several Fortran compilers, the implementation methods are
already well known.
</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>
  ISO/IEC 1539:1991 (E) 5.1.2, 5.2
</REFERENCE>

<HISTORY>
<EVENT>     May 1996, meeting 137: submitted 96-074
</HISTORY>
</FORTREQ>
**********************************************************************************************
<FORTREQ>
<NUMBER>
<TITLE>        Piecewise Construction of Named Constant Arrays
<KEYWORDS>
<STATUS>    Registered
<TARGET>
<SUBGROUP>
<VERSION>   1

<REQUIREMENT>
  Fortran 2000 should allow a programmer to construct arrays which are
named constants (i.e., have the PARAMETER attribute) in several statements.
</REQUIREMENT>

<JUSTIFICATION>
  The current Fortran 90 standard and Fortran 95 DIS require that arrays
which are named constants be completely constructed in the same statement
in which they are declared.  This restriction places a stringent limit on the
length of such an array.  It also increases program complexity and decreases
program understandability since such declarations sometimes require lengthy
declaration statements with many continuation lines.

  According to Jens Bloch Helmers of Det Norske Veritas Research, large
sized arrays of named constants are useful in certain fields of research and
engineering.
</JUSTIFICATION>

<SUGGESTED IMPLEMENTATION>
  One possible method would be to remove the restriction that named
constants need to be initialized in the same statement in which they are
declared.  Then the application developer could use successive PARAMETER
statements to initialize successive parts of the array.
</SUGGESTED IMPLEMENTATION>

<ESTIMATED IMPACT>
  It is difficult to estimate how much effort it would take for vendors to
implement this requirement.
</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>
  ISO/IEC 1539:1991 (E) 5.1, 5.2.1.2, 5.2.9
</REFERENCE>

<HISTORY>
<EVENT>     May 1996, meeting 137: submitted 96-074
</HISTORY>
</FORTREQ>
**********************************************************************************************
<FORTREQ>
<NUMBER>
<TITLE>        Period as Derived Type Delimiter
<KEYWORDS>
<STATUS>    Registered
<TARGET>
<SUBGROUP>
<VERSION>   1

<REQUIREMENT>
  Fortran 2000 should recognize the use of the period (.) as a delimiter in
derived types in addition to the percent sign (%).
</REQUIREMENT>

<JUSTIFICATION>
  The main reason is aesthetic.  The period in this context is easier to read.
This is shown by the choice of the period as the derived type delimiter in most
other languages that support derived types, including Pascal, C, and C++.
</JUSTIFICATION>

<SUGGESTED IMPLEMENTATION>
  Change the rule to allow either a period or percent sign as the delimiter.
</SUGGESTED IMPLEMENTATION>

<ESTIMATED IMPACT>
  This feature may cause a conflict with user-defined operators.  This conflict
could be resolved by defining one to have a higher precedence than the other.
Implementation costs should be moderate at worst.  There may need to be
some extra syntax checking.
</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>
  ISO/IEC 1539:1991 (E) 6.1.2
</REFERENCE>

<HISTORY>
<EVENT>     May 1996, meeting 137: submitted 96-074
</HISTORY>
</FORTREQ>
**********************************************************************************************
<FORTREQ>
<NUMBER>
<TITLE>        Floating Point Operations in Initialization Expressions
<KEYWORDS>
<STATUS>    Registered
<TARGET>
<SUBGROUP>
<VERSION>   1

<REQUIREMENT>
  Fortran 2000 should allow the use of any floating point data objects,
functions, and operations in an initialization expression.  I.e., the Fortran 2000
standard should remove all current restrictions on the use of floating point
data objects, functions, and operations in initialization expressions.
</REQUIREMENT>

<JUSTIFICATION>
  The current Fortran 90 standard and the Fortran 95 DIS restricts the use
of floating point data objects in initialization expressions.  It does not allow the
use of floating point exponents nor the use of floating point functions.  These
limits unnecessarily restrict the freedom of the application developer.  If these
restrictions are removed, the application developer can initialize data objects
using more intuitive and straightforward methods.  Thus, this feature would
increase programmer productivity.

  The current restrictions may have been necessary in earlier days when
machine time was extremely expensive and computing complex floating point
operations would have greatly increased the time required for compilation.
Today, the cost of programmer time greatly exceeds the cost of machine time.
This trend is expected to continue during the expected useful life of the
Fortran 2000 standard (1996-2012).
</JUSTIFICATION>

<SUGGESTED IMPLEMENTATION>
  Remove the current restrictions in section 7.1.6.1.

  Compilers could call the relevant run-time math library if necessary in
order to evaluate complex floating point operations or functions.  Such
capabilities are already available since at run time it is necessary to perform
such operations.
</SUGGESTED IMPLEMENTATION>

<ESTIMATED IMPACT>
  Minimal.  Some Fortran compilers already allow this feature as an
extension.  It would be useful to ask implementors what unforseen
complexities could result from this feature.
</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>
  ISO/IEC 1539:1991 (E) 7.1.6.1
</REFERENCE>

<HISTORY>
<EVENT>     May 1996, meeting 137: submitted 96-074
</HISTORY>
</FORTREQ>
**********************************************************************************************
<FORTREQ>
<NUMBER>
<TITLE>        Indirection and Address Operators and/or Functions
<KEYWORDS>
<STATUS>    Registered
<TARGET>
<SUBGROUP>
<VERSION>   1

<REQUIREMENT>
  Fortran 2000 should provide operators and/or functions for obtaining the
address of a data item and the value of an item given its address.
</REQUIREMENT>

<JUSTIFICATION>
  Very often, the use of operating systems procedures is made easier if this
functionality is available.  This capability could also be used for applications
in which fine control of memory is necessary.
</JUSTIFICATION>

<SUGGESTED IMPLEMENTATION>
  One possibility is to use the number sign (#) as the address operator and
the commercial at sign (@) as the indirection (i.e., value-at-address) operator.
Another option is to standardize the LOC() or %LOC() function.
Unfortunately, there is no widely used function name for the inverse (i.e.,
value-at-address) function.
</SUGGESTED IMPLEMENTATION>

<ESTIMATED IMPACT>
  Implementation costs should be quite low.  These capabilities are
implemented in many other languages.
</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>
  ISO/IEC 1539:1991 (E) 7.2
</REFERENCE>

<HISTORY>
<EVENT>     May 1996, meeting 137: submitted 96-074
</HISTORY>
</FORTREQ>
**********************************************************************************************
<FORTREQ>
<NUMBER>
<TITLE>        BLOCKSIZE= Specifier on OPEN
<KEYWORDS>
<STATUS>    Registered
<TARGET>
<SUBGROUP>
<VERSION>   1

<REQUIREMENT>
  Fortran 2000 should support the BLOCKSIZE= specifier on the OPEN
statement, as implemented as an extension in several Fortran compilers.
</REQUIREMENT>

<JUSTIFICATION>
  Many file systems allow the user to specify the size of I/O transfer blocks,
i.e., the physical record size of data transfers.  This could be used by
knowledgeable programmers to optimize I/O operations.
</JUSTIFICATION>

<SUGGESTED IMPLEMENTATION>
  This could be implemented as a BLOCKSIZE=numeric-expression keyword
in the OPEN statement.  If absent, the block size would use a processor-dependent default value.  If the operating system or file system does not
support user-specified block sizes, the use of this keyword would have no effect.
</SUGGESTED IMPLEMENTATION>

<ESTIMATED IMPACT>
  Minimal.  This keyword is already supported on several popular compilers.
</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>
  ISO/IEC 1539:1991 (E) 9.3.4
</REFERENCE>

<HISTORY>
<EVENT>     May 1996, meeting 137: submitted 96-074
</HISTORY>
</FORTREQ>
**********************************************************************************************
<FORTREQ>
<NUMBER>
<TITLE>        BUFFERCOUNT= Specifier on OPEN
<KEYWORDS>
<STATUS>    Registered
<TARGET>
<SUBGROUP>
<VERSION>   1

<REQUIREMENT>
  Fortran 2000 should support the BUFFERCOUNT= specifier on the OPEN
statement, as implemented as an extension in several Fortran compilers.
</REQUIREMENT>

<JUSTIFICATION>
  Many file systems allow the user to specify the number of I/O buffers. This
could be used by knowledgeable programmers to optimize I/O operations.
</JUSTIFICATION>

<SUGGESTED IMPLEMENTATION>
  This could be implemented as a BUFFERCOUNT=numeric-expression
keyword in the OPEN statement.  If absent, the buffer count would use a
processor-dependent default value.  If the operating system or file system does
not support user-specified buffer counts, the use of this keyword would have
no effect.
</SUGGESTED IMPLEMENTATION>

<ESTIMATED IMPACT>
  Minimal.  This keyword is already supported on several popular compilers.
</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>
  ISO/IEC 1539:1991 (E) 9.3.4
</REFERENCE>

<HISTORY>
<EVENT>     May 1996, meeting 137: submitted 96-074
</HISTORY>
</FORTREQ>
**********************************************************************************************
<FORTREQ>
<NUMBER>
<TITLE>        CARRIAGECONTROL= Specifier on OPEN
<KEYWORDS>
<STATUS>    Registered
<TARGET>
<SUBGROUP>
<VERSION>   1

<REQUIREMENT>
  Fortran 2000 should support the CARRIAGECONTROL= specifier on the
OPEN statement, as implemented as an extension in several Fortran
compilers.
</REQUIREMENT>

<JUSTIFICATION>
  Many Fortran processors allow the user to specify the kind of carriage
control which is used on the file during I/O operations.  This specifier would
allow the programmer to specify the carriage control rather than being
required to use the carriage control which is mandated by the Fortran compiler
for that particular kind of file.
</JUSTIFICATION>

<SUGGESTED IMPLEMENTATION>
  This could be implemented as a CARRIAGECONTROL=character-expression keyword in the OPEN statement. The character-expression would
take one of the following values:
  FORTRAN Specifies traditional Fortran interpretation of the first
character.
  LIST      Process with single spacing between records.
  NONE      Do not use any carriage control processing.
</SUGGESTED IMPLEMENTATION>

<ESTIMATED IMPACT>
  Minimal.  This keyword is already supported on several popular compilers.
</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>
  ISO/IEC 1539:1991 (E) 9.3.4
</REFERENCE>

<HISTORY>
<EVENT>     May 1996, meeting 137: submitted 96-074
</HISTORY>
</FORTREQ>
**********************************************************************************************
<FORTREQ>
<NUMBER>
<TITLE>        INITIALSIZE= and EXTENDSIZE= Specifiers on OPEN
<KEYWORDS>
<STATUS>    Registered
<TARGET>
<SUBGROUP>
<VERSION>   1

<REQUIREMENT>
  Fortran 2000 should support the INITIALSIZE= and EXTENDSIZE=
specifiers on the OPEN statement, as implemented as an extension in several
Fortran compilers.
</REQUIREMENT>

<JUSTIFICATION>
  Many file systems allow the user to specify the initial size and extend sizes
of file.  This could be used by knowledgeable programmers to optimize I/O
operations.
</JUSTIFICATION>

<SUGGESTED IMPLEMENTATION>
  This could be implemented as INITIALSIZE=numeric-expression and
EXTENDSIZE=numeric-expression keywords in the OPEN statement.  If
absent, the initial size and extend size would use processor-dependent default
values.  If the operating system or file system does not support user-specified
initial or extend sizes, the use of this keyword would have no effect.
</SUGGESTED IMPLEMENTATION>

<ESTIMATED IMPACT>
  Minimal.  This keyword is already supported on several popular compilers.
</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>
  ISO/IEC 1539:1991 (E) 9.3.4
</REFERENCE>

<HISTORY>
<EVENT>     May 1996, meeting 137: submitted 96-074
</HISTORY>
</FORTREQ>
**********************************************************************************************
<FORTREQ>
<NUMBER>
<TITLE>        ORGANIZATION= Specifier on OPEN
<KEYWORDS>
<STATUS>    Registered
<TARGET>
<SUBGROUP>
<VERSION>   1

<REQUIREMENT>
  Fortran 2000 should support the ORGANIZATION= specifier on the OPEN
statement, as implemented as an extension in several Fortran compilers.
</REQUIREMENT>

<JUSTIFICATION>
  Some file systems allow the user to specify the organization of the file as
either sequential (no fixed size and records are organized sequentially),
relative (fixed number of fixed-length records), or indexed (some fields are
keyed for indexed file access).  Knowledgeable programmers would benefit by
being able to specify the organization which is appropriate for the application,
if such organization is available.
</JUSTIFICATION>

<SUGGESTED IMPLEMENTATION>
  This feature could be implemented by an ORGANIZATION=character-expression keyword in the OPEN statement.  The character-expression would
take one of the following values:
  SEQUENTIAL   The file does not have a fixed size and records are
organized sequentially.
  RELATIVE     The file has a fixed number of fixed-length records.
  INDEXED      The file has some fields in each record keyed for
indexed file access.
If the file system in use does not support a particular organization, the use of
the ORGANIZATION keyword would have no effect.
</SUGGESTED IMPLEMENTATION>

<ESTIMATED IMPACT>

</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>
  ISO/IEC 1539:1991 (E) 9.3.4
</REFERENCE>

<HISTORY>
<EVENT>     May 1996, meeting 137: submitted 96-074
</HISTORY>
</FORTREQ>
**********************************************************************************************
<FORTREQ>
<NUMBER>
<TITLE>        RECORDTYPE= Specifier on OPEN
<KEYWORDS>
<STATUS>    Registered
<TARGET>
<SUBGROUP>
<VERSION>   1

<REQUIREMENT>
  Fortran 2000 should support the RECORDTYPE= specifier on the OPEN
statement, as implemented as an extension in several Fortran compilers.
</REQUIREMENT>

<JUSTIFICATION>
  Some file systems allow the user to specify the record type of the file.
Knowledgeable programmers would benefit by being able to specify the record
type which is appropriate for the application, if such record type is available.
</JUSTIFICATION>

<SUGGESTED IMPLEMENTATION>
  This feature could be implemented by an RECORDTYPE=character-expression keyword in the OPEN statement.  The character-expression would
take one of the following values:
  FIXED     Specifies fixed length records.
  VARIABLE  Specifies variable length records.
  STREAM    Specifies stream records, i.e., records which have no
organization.
As an extension, a processor could offer additional record type values.
</SUGGESTED IMPLEMENTATION>

<ESTIMATED IMPACT>
  Minimal to moderate.
</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>
  ISO/IEC 1539:1991 (E) 9.3.4
</REFERENCE>

<HISTORY>
<EVENT>     May 1996, meeting 137: submitted 96-074
</HISTORY>
</FORTREQ>
**********************************************************************************************
<FORTREQ>
<NUMBER>
<TITLE>        USEROPEN= Specifier on OPEN
<KEYWORDS>
<STATUS>    Registered
<TARGET>
<SUBGROUP>
<VERSION>   1

<REQUIREMENT>
  Fortran 2000 should support the USEROPEN= specifier on the OPEN
statement, as implemented as an extension in several Fortran compilers.
</REQUIREMENT>

<JUSTIFICATION>
  Some file systems allow the user to specify a user-written external
procedure which controls the opening of the file..  Knowledgeable programmers
would benefit by being able to specify additional I/O capabilities which are not
available using the regular OPEN keywords.
</JUSTIFICATION>

<SUGGESTED IMPLEMENTATION>
  This feature could be implemented by a USEROPEN=procedure-name
keyword in the OPEN statement.  The procedure would be declared
EXTERNAL and, if it is a function, be of a processor-dependent type.
</SUGGESTED IMPLEMENTATION>

<ESTIMATED IMPACT>
  Minimal to moderate.
</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>
  ISO/IEC 1539:1991 (E) 9.3.4
</REFERENCE>

<HISTORY>
<EVENT>     May 1996, meeting 137: submitted 96-074
</HISTORY>
</FORTREQ>
**********************************************************************************************
<FORTREQ>
<NUMBER>
<TITLE>        UNLOCK Statement
<KEYWORDS>
<STATUS>    Registered
<TARGET>
<SUBGROUP>
<VERSION>   1

<REQUIREMENT>
  Fortran 2000 should allow a programmer to unlock the most recently read
or written record without depending on processor, operating system, or file
system defaults.
</REQUIREMENT>

<JUSTIFICATION>
  Many operating systems and file systems lock records when they are read
or written.  In many cases, the record is unlocked at an indeterminate time.
This can cause problems in shared file applications and certain other
situations.  It would be helpful to give to the application programmer the
ability to force the unlocking of records.
</JUSTIFICATION>

<SUGGESTED IMPLEMENTATION>
  This could be implemented by creating a statement of the form:
  UNLOCK ([UNIT=]io-unit [, ERR=label] [, IOSTAT=iostatus])
where:
  io-unit   is an I/O unit number
  label     is a label of a branch target statement that receives control if
there is an error
  iostatus  is a scalar integer variable that is defined as a processor-dependent positive integer if there is an error and as zero if
            there is no error

  If there is no record locked at the time the UNLOCK statement is
executed, the statement has no effect.
</SUGGESTED IMPLEMENTATION>

<ESTIMATED IMPACT>
     Implementation costs should be quite low since record locking is a
function which is inherent to the READ and WRITE operations.
</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>
  ISO/IEC 1539:1991 (E) 9.3, 9.4
</REFERENCE>

<HISTORY>
<EVENT>     May 1996, meeting 137: submitted 96-074
</HISTORY>
</FORTREQ>
**********************************************************************************************
<FORTREQ>
<NUMBER>
<TITLE>        $ and \ Edit Descriptors
<KEYWORDS>
<STATUS>    Registered
<TARGET>
<SUBGROUP>
<VERSION>   1

<REQUIREMENT>
  Fortran 2000 should include support for the $ and \ edit descriptors, as
implemented as extensions in several Fortran compilers.
</REQUIREMENT>

<JUSTIFICATION>
  Both of these edit descriptors suppress end-of-record information at the end
of a record.  This makes it possible to concatenate two or more records in one
output line or to create prompting.  The $ edit descriptor is an extension in the
Cray, DEC, EPC, HP, IBM, Lahey, and Sun compilers.
</JUSTIFICATION>

<SUGGESTED IMPLEMENTATION>
  The Fortran 2000 standard should implement these edit descriptors as
defined in the above mentioned compilers.
</SUGGESTED IMPLEMENTATION>

<ESTIMATED IMPACT>
  The impact of implementing these edit descriptors should not be great.
The algorithms already exist.
</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>
  ISO/IEC 1539:1991 (E) 10.2.1
</REFERENCE>

<HISTORY>
<EVENT>     May 1996, meeting 137: submitted 96-074
</HISTORY>
</FORTREQ>
**********************************************************************************************
<FORTREQ>
<NUMBER>
<TITLE>        Q Edit Descriptor (Input Character Count Editing)
<KEYWORDS>
<STATUS>    Registered
<TARGET>
<SUBGROUP>
<VERSION>   1

<REQUIREMENT>
  Fortran 2000 should support the Q edit descriptor, as implemented as an
extension in several Fortran compilers.  This edit descriptor obtains the
number of characters remaining in the current input record.
</REQUIREMENT>

<JUSTIFICATION>
  It is often very useful to obtain a count of the remaining characters in an
input record, right in the middle of the input record.  The support for the Q
edit descriptors an extension in the DEC, EPC, IBM, Lahey, and Sun compilers
attests to the popularity and usefulness of this feature.
</JUSTIFICATION>

<SUGGESTED IMPLEMENTATION>
  On input, if a Q edit descriptor corresponds to a scalar integer variable, the
integer variable is set to the number of characters remaining in the input
record.  If the corresponding input variable is some other data type, an error
occurs.  On output, the corresponding output list element is ignored.
</SUGGESTED IMPLEMENTATION>

<ESTIMATED IMPACT>
  Since this is a popular extension, the algorithms are well know.  Therefore,
it should be fairly inexpensive to implement this feature.
</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>
  ISO/IEC 1539:1991 (E) 10.2.1
</REFERENCE>

<HISTORY>
<EVENT>     May 1996, meeting 137: submitted 96-074
</HISTORY>
</FORTREQ>
**********************************************************************************************
<FORTREQ>
<NUMBER>
<TITLE>        Field and Record Justification
<KEYWORDS>
<STATUS>    Registered
<TARGET>
<SUBGROUP>
<VERSION>   1

<REQUIREMENT>
  Fortran 2000 should provide edit descriptors which allow the user to
specify whether a particular field is right justified, center justified, or left
justified.  If justification is not specified, it would default to the current rules.
</REQUIREMENT>

<JUSTIFICATION>
  The current Fortran 90 standard and the Fortran 95 DIS only allow
justification as defined by the standard.  If the programmer could specify field
and record justification, s/he could produce much better aligned output with
much less effort.  Right now, it takes quite a lot of effort on the programmer's
part in order to justify output, especially if it is to be centered on a record.
</JUSTIFICATION>

<SUGGESTED IMPLEMENTATION>
  One method would be to precede each field with JR for right justification,
JL for left justification, and JC for center justification, with the target field
immediately following in parentheses.  Specifying JR, JC, or JL at the
beginning of a record could specify justification for entire records.
Investigation may reveal more effective methods for implementing each of
these features.
</SUGGESTED IMPLEMENTATION>

<ESTIMATED IMPACT>
  Unknown.  This may be fairly easy to implement or there may be
unforseen complications.  However, the existence of this feature in almost all
word processing and spreadsheet software indicates that the algorithms are
already highly developed and well known.
</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>
  ISO/IEC 1539:1991 (E) 10.2.1
</REFERENCE>

<HISTORY>
<EVENT>     May 1996, meeting 137: submitted 96-074
</HISTORY>
</FORTREQ>
**********************************************************************************************
<FORTREQ>
<NUMBER>
<TITLE>        Prohibit Embedded Blanks in Edit Descriptors
<KEYWORDS>
<STATUS>    Registered
<TARGET>
<SUBGROUP>
<VERSION>   1

<REQUIREMENT>
  Fortran 2000 should require that format edit descriptors not contain
embedded blanks, except for character strings appearing inside quotes or
parentheses.
</REQUIREMENT>

<JUSTIFICATION>
  A Fortran 90 interpretation allowed embedded blanks to appear in format
edit descriptors.  This is counter-intuitive.  It is contrary to the practice of the
last 1000 years (in Western languages) whereby blanks signify the separation
of words and tokens.  A format edit descriptor is a single token or "word" in
the eyes of application developers.  Therefore, embedded blanks should not be
allowed inside of edit descriptors.
</JUSTIFICATION>

<SUGGESTED IMPLEMENTATION>
  This could be implemented by changing the rules in section 10.2.1
governing the format of edit descriptors.
</SUGGESTED IMPLEMENTATION>

<ESTIMATED IMPACT>
  Minimal.  Some implementors will have to modify their compilers in order
to comply with the new rule.  Some users who used blanks embedded in format
edit descriptors will have to restructure their code.
</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>
  ISO/IEC 1539:1991 (E) 10.2.1
</REFERENCE>

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