######################################################################
# #
# X3J3/93-004r6 #
# Journal Of Requirements #
# #
# Dec 1993 #
# #
######################################################################
No. Stat Trgt Title
001 Arch Bit Data Type, Non-string
002 Reg Variant Derived Type
003 Reg Array Components of Array Structures
| 004 US 1995 FORALL
005 Arch DIAGONAL Function
006 Arch PROJECT Function
007 Arch REPLICATE Function
008 Arch RANK Intrinsic Function
009 Arch FIRSTLOC and LASTLOC intrinsics
| 010 US Nesting of Internal Procedures
011 Arch Internal Procedure Names as Actual Arguments
| 012 US 2000 Condition Handling
013 Reg Pointer Initialization
| 014 X3J3 Language Management
| 015 US 1995 Conditional Compilation
| 016 X3J3 1995 Command Line Arguments and Environmental Variables
| 017 US 2000 Bit Data Type, String
| 018 US 2000 Controlling Pointer Bounds
019 Reg Variant Derived Type, Untagged
020 Reg User Defined Elemental Functions
021 Reg Obsolesce Fixed Source Form
022 Reg Keep It Simple, Make It Fine
023 Reg User Defined Intrinsic Functions
024 Reg Nested WHERE Statements
025 Reg Pure User Functions and Subroutines
| 026 Arch Directives
027 Reg Packaging Implementer Specific Intrinsics in MODULEs
028 Reg Binding to IEEE 754
| 029 Arch Interline Optimization
030 Reg Variable Rank Arrays
| 031 X3J3 1995 Varying Length Character with Declared Maximum
032 Reg POSIX Binding to Fortran 90
033 Reg Object Oriented Fortran, OOF
034 Reg Variable Repeat Specifiers in Formats
035 Reg Specifying Default Precisions
036 Reg MAXLOC and MINLOC To Accept CHARACTER Arguments
037 Reg Argument Passing Mechanism
038 Reg Complete Set of Compiler Directives
039 Reg SYSTEM Command
040 Reg Obtain the Command Line
041 Reg Obtain Program Startup Command
042 Reg Indexed Files
043 Reg OOP Capabilities
044 Reg Unsigned INTEGER Data Type
045 Reg Unicode Character Set Support
046 Reg Row Major Arrays
047 Reg File Sharing Modes
| 048 Reg Improve Interoperability between Fortran and ANSI C
INTRODUCTION
This document is the Journal of Requirements, or JOR, an internal
working document of X3J3, the US Technical Committee with
responsibility for Fortran under the procedures of the American
National Standards Institute. It contains proposed Fortran
Requirements, or pFRs, i.e., proposals for future revisions or
additions to the Fortran family of standards. This is an evolving
document, and it is expected that pFRs will be added and updated from
time to time. The current version of the JOR may be obtained by
anonymous ftp from directory /x3j3 at ftp.ncsa.uiuc.edu. This
directory can also be accessed via an email archive server. To find
out how to use it, send email to archive-server@ncsa.uiuc.edu with the
command "help" on a single line in the body of the message.
Proposals are accepted for inclusion in this document from any member
of the US Fortran community provided only that they adhere to a few
editorial guidelines. For information on proposing a requirement, see
the document pFR-call at the above ftp server, or contact the JOR
editor:
Len Moss
ljm@slac.stanford.edu
SLAC MS 97
P. O. Box 4349
Stanford, CA 94309
phone: 415-926-3370
Inclusion of a pFR in the JOR does not imply its approval by X3J3
unless such approval is explicitly noted in the status field (see
below). Moreover, there is no commitment on the part of X3J3 to
fulfill any of the pFRs in this document, regardless of their status
fields, since the international Fortran committee (ISO/IEC
JTC1/SC22/WG5) has final authority over all future Fortran standards.
The status of each item in this document is tracked with the STATUS
field, the values (abbreviations) of which are:
Registered (Reg)
Received and assigned a number by the requirements editor, and
incorporated into the next revision of this standing document.
| X3J3 approved; ready for US TAG (X3J3)
| Submitted for approval by the US TAG by a majority vote of X3J3.
| A target revision cycle may optionally be included.
|
| US TAG approved; ready for WG5 (US)
| Accepted by US TAG without objections within one week of X3J3
| approval; or by majority vote of US TAG. Forwarded to WG5.
|
| WG5 approved (WG5)
| Approved by WG5 with a target revision cycle.
Satisfied (Sat)
Substantially satisfied in a new revision of the Fortran, or a
related, standard, as determined by a two-thirds vote of X3J3.
Failed WG5 approval (Fail)
Failed to gain approval by WG5 after forwarding from X3J3.
| This status is equivalent to "Registered".
Archival (Arch)
Withdrawn from active consideration by X3J3; requires a
two-thirds vote of the committee.
######################################################################
001
Bit Data Type, Non-string
BIT, INTRINSIC, DATA TYPE
Archival
----------------------------------------------------------------------
002
Variant Derived Type
DERIVED TYPE, VARIANT, TAG
Registered
|
1
Grandfather requirement from old Appendix F
Extend derived types to permit a single optional variant part. A
variant part should specify alternative sequences of components.
Only one such sequence would have an interpretation at any given
time in a structure of that type; this "active" sequence would be
determined by the value of a "tag", i.e., a non-variant component of
the type.
[To be supplied if the STATUS is changed from "Registered" to "X3J3
consideration in progress". Requirement "grandfathered".]
Use a syntax similar to that of the SELECT CASE construct, including
an optional DEFAULT case, for the variant part of the derived type
definition, but with nesting and construct names prohibited.
Require that the variant part, if present, must occur at the end of
the type definition and must be immediately preceded by the
nonvariant tag component. Specify that redefinition or undefinition
of the tag component results in the undefinition of all variant
components of the structure.
No impact on existing code.
[ Section F.1.2 of S8.104 Appendix F (aka X3J3/119-LJM-1)
]
X3J3
Apr 93:
Section F.1.2 of S8.104 Appendix F material reformatted by L. Moss.
Feb 93, meeting 124:
X3J3/S17 (JOD), less vector-valued subscripts and significant
blanks, becomes X3J3/93-004, Journal Of Requirements as part of
chair's reorganization of X3J3 (see 92-181).
Nov 87, Meeting 106:
Conversion of S8.104 Appendix F to X3J3/S17, Journal Of Development,
approved by X3J3 (18-12).
----------------------------------------------------------------------
003
Array Components of Array Structures
ARRAYS, STRUCTURES, COMPONENTS, RANK, SHAPE
Registered
|
1
Grandfather requirement from old Appendix F
Treat array structures containing array components as higher-rank
array objects; that is, remove the restriction against structure
references containing more than one part-ref> with non-zero
rank. Interpret the shape of such a reference to be (/ C, P /),
where P is the shape of the parent and C is the shape of the
component.
[To be supplied if the STATUS is changed from "Registered" to "X3J3
consideration in progress". Requirement "grandfathered".]
[ Section F.2.1 of S8.104 Appendix F (aka X3J3/119-LJM-1)
]
X3J3
May 93, Meeting 125:
Straw vote to change status to approved/archival/undecided: 8-4-12;
no change.
Apr 93:
Section F.2.1 of S8.104 Appendix F material reformatted by L. Moss.
Feb 93, meeting 124:
X3J3/S17 (JOD), less vector-valued subscripts and significant
blanks, becomes X3J3/93-004, Journal Of Requirements as part of
chair's reorganization of X3J3 (see 92-181).
Nov 87, Meeting 106:
Conversion of S8.104 Appendix F to X3J3/S17, Journal Of Development,
approved by X3J3 (18-12).
----------------------------------------------------------------------
004
FORALL
FORALL, STATEMENT, CONSTRUCT, ELEMENT ARRAY ASSIGNMENT
| US TAG approved; ready for WG5
| 1995 revision
1
Grandfather requirement from old Appendix F
Add a FORALL statement or construct, or both, to perform array
assignments in terms of a set of array element or array section
assignments. The array elements or sections and their corresponding
right-hand-side expressions are determined by a set of subscript
names (with a scope of the FORALL statement or construct), each of
which takes on, in no predetermined order, the set of values
determined by a triplet notation similar to that used for a
subscript-triplet>. An optional mask, consisting of a scalar
logical expression which also depends on the FORALL subscripts, may
be specified to control the execution of the individual
sub-assignments. The order in which the individual element or
section assignments are made is not defined; however, all
expressions on the right hand side corresponding to true values of
the mask expression (if present) should be evaluated before any
assignments are made to the left hand side. No element of the
array may be assigned a value more than once.
[To be supplied. Requirement "grandfathered".]
The FORALL construct of HPF.
No impact on programs conforming to Fortran 90; however,
note that an implementation incompatible with that of HPF
could cause significant problems for many Fortran users.
[ HPF
][ Section F.2.3 of S8.104 Appendix F (aka X3J3/119-LJM-1)
]
X3J3
| Nov 93:
| Without objections from US TAG following Nov 93 X3J3 meeting,
| automatically promoted to "US TAG approved; ready for WG5".
Jul 93, WG5 meeting:
WG5 tentatively approved for 1995 revision (resolution B9, items
A2 and A3)
May 93, meeting 125:
Status changed to approved/1995 (UC).
Apr 93:
Section F.2.3 of S8.104 Appendix F material reformatted by L. Moss.
Feb 93, meeting 124:
Status of FORALL statement portion of S8.104 Appendix F material,
amended to include a FORALL construct, changed to "X3J3
consideration in progress" (18-0).
Feb 93, meeting 124:
X3J3/S17 (JOD), less vector-valued subscripts and significant
blanks, becomes X3J3/93-004, Journal Of Requirements as part of
chair's reorganization of X3J3 (see 92-181).
Nov 87, Meeting 106:
Conversion of S8.104 Appendix F to X3J3/S17, Journal Of Development,
approved by X3J3 (18-12).
----------------------------------------------------------------------
005
DIAGONAL Function
DIAGONAL, FUNCTION, ARRAY, FILL, MATRIX, VECTOR
Archival
----------------------------------------------------------------------
006
PROJECT Function
PROJECT, FUNCTION, ARRAY, MASK, FIELD, REDUCE RANK
Archival
----------------------------------------------------------------------
007
REPLICATE Function
REPLICATE, FUNCTION, ARRAY
Archival
----------------------------------------------------------------------
008
RANK Intrinsic Function
RANK, INTRINSIC, INQUIRY FUNCTION
Archival
----------------------------------------------------------------------
009
FIRSTLOC and LASTLOC intrinsics
FIRSTLOC, LASTLOC, INTRINSIC
Archival
----------------------------------------------------------------------
010
Nesting of Internal Procedures
INTERNAL PROCEDURES, NESTING
| US TAG approved; ready for WG5
|
1
Grandfather requirement from old Appendix F
An internal procedure may host other internal procedures.
[To be supplied if the STATUS is changed from "Registered" to "X3J3
consideration in progress". Requirement "grandfathered".]
This will not directly affect existing code.
[ Section F.3.1 of S8.104 Appendix F (aka X3J3/119-LJM-1)
]
X3J3
| Nov 93:
| Without objections from US TAG following Nov 93 X3J3 meeting,
| automatically promoted to "US TAG approved; ready for WG5".
| Nov 93, meeting 127:
| Motion to approve for 2000 passed (16-1) (note change in procedures
| to require only a simple majority to approve); subsequently changed
| target to unspecified by unanimous consent.
May 93, meeting 125:
Motion to approve for 2000 failed two-thirds vote (15-1); unchanged.
Mar 93:
Section F.3.1 of S8.104 Appendix F material reformatted by
D. Mattoon.
Feb 93, meeting 124:
X3J3/S17 (JOD), less vector-valued subscripts and significant
blanks, becomes X3J3/93-004, Journal Of Requirements as part of
chair's reorganization of X3J3 (see 92-181).
Nov 87, Meeting 106:
Conversion of S8.104 Appendix F to X3J3/S17, Journal Of Development,
approved by X3J3 (18-12).
----------------------------------------------------------------------
011
Internal Procedure Names as Actual Arguments
INTERNAL PROCEDURES, ARGUMENTS
Archival
----------------------------------------------------------------------
012
Condition Handling
CONDITION, ENABLE, SIGNAL, HANDLER, EXCEPTION
| US TAG approved; ready for WG5
| 2000 revision
1
Grandfather requirement from old Appendix F
|
| Related to pFR 28 (Binding to IEEE 754) and pFR 32 (POSIX binding
| to Fortran 90)
|
Provide a structured way of dealing with relatively rare,
synchronous events, such as error in input data or instability of an
algorithm near a critical point. The condition handling mechanism
must have the following characteristics:
- Automatic detection and signalling (when enabled) of a
standard set of intrinsic conditions, including at least: numeric
errors, subscript and substring bounds errors, I/O errors, end of
file, and allocation errors. Additional, processor-dependent
intrinsic conditions should also be allowed.
- User-defined conditions, declared with a new specification
statement and signalled explicitly by a new executable
statement.
- Dummy condition arguments.
- Independent enabling and/or disabling of intrinsic
conditions, on a granularity finer than that of a scoping unit; that
is, it should be possible to enable an intrinsic condition only for
a block of statements, possibly even a single statement, in a
scoping unit.
- Minimal impact on code performance within the innermost
condition-handling block or scoping unit. In other words, entities
in the innermost block or scoping unit should be permitted to become
undefined when a condition is signalled when necessary to avoid
extra processor overhead.
- When a condition is signalled, a search should be made up the
chain of nested, enabled condition-handling blocks and scoping units
for an associated user-written handler, and control should be
transferred to the first such handler found. If no handler is
found, the result is processor dependent. A handler should be able
to resignal the condition that activated it.
- Default handlers to handle any condition.
- Appropriate inquiry functions to determine whether a
condition has been enabled and whether a handler has been
established for it.
[To be supplied if the STATUS is changed from "Registered" to "X3J3
consideration in progress". Requirement "grandfathered".]
See section of S8.104 Appendix F.
[ Section F.4.1 of S8.104 Appendix F (aka X3J3/119-LJM-1)
]
X3J3
| Nov 93:
| Without objections from US TAG following Nov 93 X3J3 meeting,
| automatically promoted to "US TAG approved; ready for WG5".
| Nov 93, meeting 127:
| Tutorial presented on general subject of exception handling. Straw
| vote on pursuing: for F95 | for F2K | later |undecided (6-13-0-1).
| Straw vote on continuing work now, targeted at F2K (18-1-0). Straw
| vote on: minimal solution | expanded solution | undecided (4-6-7).
Jul 93, WG5 meeting:
Investigation for 1995 revision requested (B9 Resolution, item C5)
May 93, meeting 125:
Status changed to approved/2000 (20-2).
Apr 93:
Section F.4.1 of S8.104 Appendix F material reformatted by L. Moss.
Feb 93, meeting 124:
X3J3/S17 (JOD), less vector-valued subscripts and significant
blanks, becomes X3J3/93-004, Journal Of Requirements as part of
chair's reorganization of X3J3 (see 92-181).
Nov 87, Meeting 106:
Conversion of S8.104 Appendix F to X3J3/S17, Journal Of Development,
approved by X3J3 (18-12).
----------------------------------------------------------------------
013
Pointer Initialization
POINTER, INITIALIZATION, DISASSOCIATED, UNDEFINED
Registered
|
1
Change the initial status of pointers from undefined to
disassociated.
The varying length character string module has demonstrated the need
for garbage collection -- either user-supplied or
processor-supplied. Garbage collection is difficult, if not
impossible, without automatic initialization of pointers. Pointer
initialization will also improve the safety and security of
programs, and it will relieve programmers of the tedium of inserting
statements to initialize pointers.
This affects only the pointer facility. It will not invalidate any
existing programs; it will cause some overhead for compilers and
possibly for program execution.
[ Item 1 of ISO/IEC JTC1/SC22/WG5-N871.
]
X3J3/JOR subgroup for DIN Fortran Working Group
Jul 93, WG5 meeting:
WG5 recommended for 1995 revision (resolution B9, item B1)
May 93, meeting 1254:
Straw vote to change status to approved/archival/undecided: 7-8-10;
no change.
Feb 93, meeting 124:
Vote to change the status to "X3J3 consideration in progress"
fails (8-9).
Feb 93, meeting 124:
Registered by X3J3/JOR subgroup on behalf of DIN Fortran Working
Group.
Jul 92, WG5 Meeting:
Presented to WG5 by Wolfgang Walter of DIN Fortran Working Group.
----------------------------------------------------------------------
014
Language Management
EVOLUTION, OBSOLESCENT
| X3J3 approved; ready for US TAG
|
1
A management plan for language evolution: move redundant features to
the obsolescent list, design strategic functionality, and integrate
the whole into a coherent language.
A language cannot continue to grow forever by the addition of new
features. There must be some cleansing, that is, the removal of
features no longer needed or features whose functionality is
provided by "better" features.
While the language would be improved, suppliers of processors would
have to provide means to process existing code, such as continuing
to support removed features or providing translators.
[ Item 3 of ISO/IEC JTC1/SC22/WG5-N871.
][ ISO/IEC JTC1/SC22/WG5-N817.
][ ISO/IEC JTC1/SC22/WG5-N781.
]
X3J3/JOR subgroup for Aurelio Policini
| Dec 93:
| Status promoted to "X3J3 approved; ready for WG5" with an unspecified
| target date by JOR editor; action taken because X3J3 reduced the
| requirement for this status to a simple majority at meeting 126 (Jul
| 93), thus effectively subsuming the status of "X3J3 consideration in
| progress". Due to irregular nature of this change, US TAG approval
| not assumed pending next US TAG meeting.
Jul 93, WG5 meeting:
WG5 recommended for 1995 revision (resolution B9, item B4.2)
May 93, meeting 125:
Straw vote to change status to approved/archival/undecided: 9-3-8;
no change.
Feb 93, meeting 124:
Status changed to "X3J3 consideration in progress" (9-3).
Feb 93, meeting 124:
Registered by X3J3/JOR subgroup on behalf of Aurelio Policini.
Jul 92, WG5 Meeting:
Presented to WG5 by Aurelio Policini.
----------------------------------------------------------------------
015
Conditional Compilation
CONDITIONAL COMPILATION, PREPROCESSOR
| US TAG approved; ready for WG5
| 1995 revision
1
Permit the conditional inclusion of Fortran statements
(declarations, executable constructs, comment lines, procedures,
etc.) in programs. The conditions are based on the values of
compile-time variables.
This would permit users to maintain only one version of a source for
use on various systems or under various conditions. The C language
has such facilities and users have found them invaluable.
No impact on existing programs. Would add slightly to the burden of
implementers.
[ Item 6 of ISO/IEC JTC1/SC22/WG5-N871.
][ ISO/IEC JTC1/SC22/WG5-N899.
][ ISO/IEC JTC1/SC22/WG5-N539.
]
X3J3/JOR subgroup for HPFF
| Nov 93:
| Without objections from US TAG following Nov 93 X3J3 meeting,
| automatically promoted to "US TAG approved; ready for WG5".
May 93, meeting 125:
Status changed to approved/1995 (18-6).
May 93, meeting 125:
Motion to approve for 2000 failed two-thirds vote (15-1).
Feb 93, meeting 124:
Status changed to "X3J3 consideration in progress" (14-2).
Feb 93, meeting 124:
Registered by X3J3/JOR subgroup on behalf of HPFF.
Dec 92:
Brought up in HPF deliberations in December 1992. A letter of
request from HPFF is forthcoming; no formal request has been
received as yet. This feature was also suggested in the Fortran 90
Implementers Workshop in 1991.
----------------------------------------------------------------------
016
Command Line Arguments and Environmental Variables
COMMAND LINE
X3J3 approved; ready for US TAG
| 1995 revision
2
|
| Related to pFR 32 (POSIX binding to Fortran 90)
|
Provide a standard method to retrieve the command line arguments.
This capability is analogous to the ARGC/ARGV convention of ANSI-C.
Although not a fundamental requirement, also provide a standard
method to retrieve environmental variables.
Getting command line arguments is obviously
desirable since it has been implemented in a vendor-specific manner
on a wide variety of machines and a wide variety of compilers. The
basic functionality appears to be common among implementations.
However, there appears to be no de facto standard means to specify
it.
Some systems also offer environmental variables, symbols, or logical
device names. Some of this functionality could be incorporated by
an intrinsic which when passed a character variable returns a
processor-defined result. When this character variable is omitted,
the command line is returned.
Not all environments have a command line to return. However,
an implementation should return a status field and one status can be
that there is no processor-defined command line to return. By
analogy, the DATE_AND_TIME intrinsic is provided even though some
systems do not have real-time clocks.
A summary of some vendor-specific
implementations:
- Microsoft Fortran: NARGS() is a function which returns the
number of arguments. GETARG(THSARG,ARGMNT,STATUS) is a subroutine
where THSARG specifies which command line argument is desired
(0=program name), ARGMNT is the actual command line argument, and
STATUS is a status: if < 0, an error occurred. If > 0, it is the
length of the command line argument returned
- Lahey Fortran: subroutine GETCL returns a string containing
the command tail -- everything after the command and the blank
separator.
- HP has a function IARGC() which returns the number of
arguments and a subroutine GETARG(THSARG,ARG) which returns the
THSARG-th argument from the built-in ARG array.
- VAX-VMS Fortran requires that the program be invoked as a
"foreign command." Subroutine LIB$GET_FOREIGN (COMMAND_LINE, PROMPT,
COMMAND_LEN, FLAGS) is called where COMMAND_LINE returns the command
line tail, PROMPT displays a prompt for the user to supply a command
line tail interactively, COMMAND_LEN optionally returns the length
of the command line tail, and FLAGS is an argument for a "utility
command collector" not needed for this application.
- IBM AIX/6000: GETARG(I, C) is a subroutine where I specifies
which command line argument to return (0=program name), C is an
argument of type character and will contain, upon return from
GETARG, the command line argument. Subroutine
GETENV('ENVNAM',RESULT) stores in character variable RESULT the
value of the environmental variable ENVNAM in the profile file of
the current directory.
A proposed format for this intrinsic or group of intrinsics has not
been provided since other existing implementations should be
considered. However, some of the facilities in the POSIX binding to
Fortran 77 already provide this functionality and should be
seriously considered.
Desirable features are:
- Parallel syntax or optional arguments to specify either
environmental variables or the command line.
- Ability to treat the command line as either a string or as a
series of arguments. This is similar to the DATE/TIME vs VALUES
option in the DATE_AND_TIME routine.
- Ability to provide an error status including the fact that no
command line can be provided or the specified environmental variable
did not exist.
- Automatic parsing of the command line based on blank
delimiters since many users want this feature without the bother of
using the string intrinsics.
- Allowing for systems which can only return the command line
tail vs systems which can return the full command line.
Open issues may include:
- How to specify the length of the character variables for the
command line arguments.
- How to specify the dimension of the array returning the
command line arguments.
This should not have an effect on existing code unless the
intrinsic(s) clash with existing procedure names.
[ Specified in a request from Boeing (X3J3/93-069). Expanded
and generalized by David Mattoon.
][ POSIX Fortran 77 binding.
]
David Mattoon
| Nov 93, meeting 127:
| /JOR subgroup requested deferral of US TAG approval pending
| a consideration of subsuming this requirement under pFR 032 (POSIX
| binding to Fortran 90).
May 93, meeting 125:
Status changed to approved/1995 (21-1).
May 93, meeting 125:
Motion to approve for 2000 failed (7-12).
May 93, meeting 125:
First proposal submitted by David Mattoon.
----------------------------------------------------------------------
017
Bit Data Type, String
BIT, INTRINSIC, DATA TYPE, STRING
| US TAG approved; ready for WG5
| 2000 revision
2
Add BIT data type using the syntax and semantics of CHARACTER type,
i.e., declaration syntax would be identical to CHARACTER except for
the word BIT. BIT initialization, substring operation,
concatenation, and input/output would also parallel CHARACTER.
Add the attribute UNSIGNED. The attribute's interpretation is
discussed further below.
Operators: Concatenation (//), the INTEGER arithmetic operators (+,
-, *, /, **, .NE., .LT., ...) and the LOGICAL operators (.NOT.,
.AND., .OR., .EQV., and .NEQV.) which are Boolean when they are used
with BIT operands. LOGICAL and BIT operands may not be mixed, i.e.,
a BIT datum is not .TRUE. or .FALSE..
In addition, consider extending the LOGICAL operators to include all
16 binary operators.
It is not necessary for WG5/X3J3 to anticipate how BIT data type
will be used, rather, the above requirements would extend all
"reasonable" combinations of possibilities to BIT data and
operations.
The UNSIGNED attribute determines how BIT operands are aligned when
the appear as an operand. Signed BIT (the default) is sign extended
and truncated similarly, e.g.,
b(5:7) = B'1111101'
has the value 101 stored into the three bits -- user beware. For
UNSIGNED, zeros filled on the left. The shift functions from the
Mil Standard are also available.
The possibility of another attribute LEFT JUSTIFY (the default is
RIGHT JUSTIFY) needs to be examined.
In an array of BIT strings, the bits of consecutive array elements
are contiguous. That is, for
BIT*11 A(27)
the first bit of A(2) immediately follows the last bit of A(1).
BIT variables cannot be EQUIVALENCEd with variables of other types,
the same as CHARACTER. But the committee should consider BIT and
CHARACTER EQUIVALENCE.
BIT variables can be placed in SEQUENCE derived types. This feature
has to be examined carefully.
Some examples:
BIT, UNSIGNED :: bu_1*1, bu_2*2, ...
BIT :: b_1*1, b_2*2, ...
...
b_2 = b_2(2:) + bu_1
b_4 = b_1 // b_2 // B'1'
IF ( 2 * bu_1 + 1 > ...
bu_2 = 2*( b_1 .AND. bu_1 )
But not:
IF ( bu_1 ) GO TO 10
Since the variables are Boolean, not LOGICAL.
Review Appendix F from earlier drafts of the Fortran Standard.
Artificial life, genetic algorithms, and cellular automata are
exciting, new (the programming community is becoming aware of them)
developments. Programming in these fields would be facilitated by
the BIT data type.
DOD utilizes (requires?) BIT data type.
Users have been requesting BIT for years.
There are implementations that should be standardized and Fortran 90
features that could be deprecated.
Most compilers could generate more efficient code if BIT were an
intrinsic type.
To be accomplished after WG5 authorization.
[ X3J3/93-119 Lahey / BIT Data Type
][ Section F.1.1 of S8.104 Appendix F (aka X3J3/119-LJM-1)
]
Thomas M. Lahey
Email: tlahe@lahey.com
| Nov 93:
| Without objections from US TAG following Nov 93 X3J3 meeting,
| automatically promoted to "US TAG approved; ready for WG5".
May 93, meeting 125:
Status changed to approved/2000 (22-2); original proposal revised by
Tom Lahey.
May 93, meeting 125:
First proposal, X3J3/93-119, submitted by Thomas Lahey
----------------------------------------------------------------------
018
Controlling Pointer Bounds
POINTERS, BOUNDS
| US TAG approved; ready for WG5
| 2000 revision
1
Allow a user to specify the bounds of a pointer that is associated
with a target by the pointer assignment statement.
Currently a pointer that is associated with a target by the pointer
assignment statement has the bounds of the target unless the target
is an array section or an array expression, in which case the lower
bound is one and the upper bound is the extent. The user has no
control over setting the bounds. This is inconsistent with the
passing of an actual argument array, array section, or array
expression to a dummy argument. The lower bound of a dummy argument
may be specified in a declaration statement. A user should have a
similar amount of control over the bounds of array pointers.
This affects only the pointer facility. It will not invalidate any
existing programs.
[ Item 2 of ISO/IEC JTC1/SC22/WG5-N871.
][ ISO/IEC JTC1/SC22/WG5-N780.
]
Jeanne Martin
Email: jtm@llnl.gov
| Nov 93:
| Without objections from US TAG following Nov 93 X3J3 meeting,
| automatically promoted to "US TAG approved; ready for WG5".
May 93, meeting 125:
Status changed to approved/2000 (17-4).
May 93, meeting 125:
Motion to approve for 1995 failed two-thirds vote (14-8).
Apr 93:
Registered.
Jul 92, WG5 Meeting:
Presented to WG5 by Jeanne Martin.
----------------------------------------------------------------------
019
Variant Derived Type, Untagged
DERIVED TYPE, VARIANT
Registered
|
1
Counter proposal to Item 2 of 93-004r
Extend derived types to permit a single optional variant part. A
variant part should specify alternative sequences of components.
Any or all of these sequences would have an interpretations at any
given time in a structure of that type. It is the responsibility of
the user to use a sequence which does have a valid interpretation.
Users of other languages find the ability to pack data in a data
structure (such as a derived type) very useful for reducing memory
requirements. Indeed, Fortran itself has always supported
EQUIVALENCE for the overlaying of data to save memory. Users of
DEC's UNION and MAP extension to FORTRAN 77 are looking for a
similar facility in a standard Fortran.
Add an EQUIVALENCE construct to derived types, in which components
which are to be overlayed in memory must be within an
EQUIVALENCE/END EQUIVALENCE construct.
For Example:
type example
integer a ! non overlayed
equivalence
integer b ! overlayed with c
integer c ! overlayed with b
end equivalence
integer d ! non overlayed
end type
type(example) x
x%b = 2
x%a = x%c ! x%a gets the value 2
The current EQUIVALENCE rules would be used inside the derived type,
as they are outside of the derived type. The storage requirements
for the equivalence construct would be the same as the largest
component inside the equivalence construct.
Groups of elements to be equivalenced can be put inside a derived
type (outside of the derived type defining the EQUIVALENCE
construct), and then included within the EQUIVALENCE construct.
No impact on existing code.
[ Item 2 of X3J3/93-004r
][ X3J3/93-164
]
Greg Lindhorst, gregli@microsoft.com, 206-936-2169
May 93, Meeting 125:
Submitted as X3J3/93-164
----------------------------------------------------------------------
020
User Defined Elemental Functions
ELEMENTAL, FUNCTION
Registered
|
1
The ability to define elemental functions.
Elemental functions are useful on parallel processors, where each
element of an array can be given to an individual processor with
user defined code to execute.
User defined elemental functions allow users to write functions
which work over all ranks of arrays without having to write a
different function for each possible rank.
Extend the language to allow the definition of elemental functions.
Add a keyword ELEMENTAL to the FUNCTION and SUBROUTINE statements,
in a similar manner to how RECURSIVE has been added. A procedure so
declared will be allowed in array expressions just as other
elemental intrinsics are in Fortran 90. The arguments to the
procedure must be scalar, and may be modified in the elemental
procedure.
For example:
subroutine go
integer ix,iy(10)
logical lx,ly(10)
lx = bitoverlap(ix,iy(1))
ly = bitoverlap(iy(1:10),iy(10:1:-1))
contains
logical elemental function bitoverlap(a,b)
integer a,b
bitoverlap = iand(a,b) .ne. 0
end function
end subroutine
No impact on existing code.
[ X3J3/93-163
]
Greg Lindhorst, gregli@microsoft.com, 206-936-2169
May 93, Meeting 125:
Submitted as X3J3/93-163
----------------------------------------------------------------------
021
Obsolesce Fixed Source Form
SOURCE FORM, OBSOLESCENT
Registered
|
1
Add fixed source form to the list of obsolescent features.
The need for language evolution by eventually removing some features
has often been noted. Fixed source form is an artifact of the days
of punched cards. It was retained in f90 for compatibility with old
code.
The blank insignificance of fixed source form places awkward
requirements on the syntax. Some future syntax additions might
therefore be less awkward if fixed source form were eliminated.
Categorizing fixed source form as obsolete would facilitate its
deletion from future standards.
Nothing required now. If fixed source form were deleted from a
subsequent standard, I would expect to see utilities to convert old
fixed source form code to free form, but vendors would not be
required to provide such a utility. Some such utilities already
exist. Vendors could choose to continue support of fixed source
form as an extension.
No immediate impact on existing
programs or processors. If fixed source form were deleted from a
subsequent standard, existing programs in fixed source form would
have to be converted to free source form.
[ X3J3/93-161
]
Richard Maine, maine@altair.dfrf.nasa.gov
Jul 93, WG5 meeting:
WG5 recommended for 1995 revision (resolution B9, item B4.2)
May 93, meeting 125:
Proposal X3J3/93-161 submitted by Richard Maine
----------------------------------------------------------------------
022
Keep It Simple, Make It Fine
SIMPLIFY, RESTRICTIONS, SYNTAX RULES, CONSTRAINTS, OBSOLESCENT
FEATURES
Registered
|
1
Simplify Fortran 95 over Fortran 90 in (at least) the following
ways.
1. Remove unnecessary restrictions such as
a. all specification ordering restrictions in the
,
b. the maximum number of characters in a name, a line, a
statement,
c. the current disallowance of redundant specifications, and
d. a number of other specific restrictions and constraints.
2. Remove those features identified as obsolescent in Fortran 90.
3. Make obsolescent those features associated with unduly complex
syntax rules and/or constraints. Typical candidates are those
parts (not necessarily all) of , ,
and that complicate the syntactical description
of these features.
Computer language technology continues to advance in sophistication,
both in terms of definition and implementation. The viable general
purpose languages of the future will be powerful yet easy to use.
The users of the future will tolerate neither restrictions due to
primitive conceptual and technological legacies from the past nor
syntactic complexity burdened with a plethora of arcane and
unnecessary rules.
Jerry Wagener, jwagener@amoco.com
May 93:
First proposal circulated via X3J3 email list by Jerry Wagener
----------------------------------------------------------------------
023
User Defined Intrinsic Functions
INTRINSICS, CONSTANT EXPRESSIONS
Registered
|
1
Provide a mechanism for user supplied functions to be used in
contexts requiring a "constant expression", typically in
specification statements.
Facilitates extensions to Fortran environments by other standard
bodies, vendors, and Fortran implementers. NUMBER_OF_PROCESSORS ()
is an example of a "compile time" intrinsic which another standards
body might wish to add.
None
[ X3J3/93-168
]
Rich Bleikamp for X3J3/parallel subgroup
bleikamp@convex.com, 214-306-6393
Jul 93, WG5 meeting:
Investigation for 1995 revision requested (B9 Resolution, item C3)
May 93, meeting 125:
Proposal X3J3/93-168 presented by Rich Bleikamp for X3J3/parallel
subgroup
----------------------------------------------------------------------
024
Nested WHERE Statements
WHERE STATEMENT, NESTING, PARALLELISM
Registered
|
1
Adding support for nested WHERE statements may be desirable for
expressing parallelism.
Facilitates extensions to Fortran environments by other standard
bodies (e.g., HPFF).
None
[ X3J3/93-167
][ ISO/IEC 1539:1991
][ High Performance Fortran
]
Rich Bleikamp for X3J3/parallel subgroup
bleikamp@convex.com, 214-306-6393
May 93, meeting 125:
Proposal X3J3/93-167 presented by Rich Bleikamp.
----------------------------------------------------------------------
025
Pure User Functions and Subroutines
FUNCTIONS, SIDE EFFECTS, FORALL, PARALLELISM
Registered
|
1
Add support for user written "pure" functions and subroutines. This
facilitates use of the block FORALL construct, by helping compilers
parallelize the execution of FORALL.
This requirement partially overlaps with another requirement, user
defined elemental functions.
Requested by other Fortran related standards groups (HPFF).
None
[ X3J3/93-169
]
Rich Bleikamp for X3J3/parallel subgroup
bleikamp@convex.com, 214-306-6393
Jul 93, WG5 meeting:
WG5 tentatively approved for 1995 revision (resolution B9, item A4)
May 93, meeting 125:
Proposal X3J3/93-169 presented by Rich Bleikamp for X3J3/parallel
subgroup
----------------------------------------------------------------------
026
Directives
DIRECTIVE, COMPILER, COMMENT
| Archival
----------------------------------------------------------------------
027
Packaging Implementer Specific Intrinsics in MODULEs
INTRINSIC PROCEDURE, MODULE
Registered
|
1
Provide a mechanism to package non-standard intrinsic packages in a
portable way. Various other standard activities are specifying new
intrinsics as extensions to Fortran, and significantly polluting the
name space. Using modules to hide these intrinsics will help reduce
name space pollution.
Facilitates extensions to Fortran environments by other standard
bodies (e.g. HPFF, X3H5, POSIX).
None
[ X3J3/93-170
][ High Performance Fortran
][ X3H5 document
]
Rich Bleikamp for X3J3/parallel subgroup
bleikamp@convex.com, 214-306-6393
May 93, meeting 125:
Proposal X3J3/93-170 presented by Rich Bleikamp for X3J3/parallel
subgroup
----------------------------------------------------------------------
028
Binding to IEEE 754
ARITHMETIC, FLOATING POINT, IEEE 754, BINDING
Registered
|
1
Bind Fortran to the IEEE standard for Binary Floating Point
Arithmetic, ANSI/IEEE 754-1985.
To be precise three things are intended:
1) Where Fortran conflicts with IEEE 754, modify
Fortran (e.g., alter Fortran to permit -0.0)
2) Where Fortran is vague on how arithmetic works,
employ the IEEE 754 definitions (e.g., formal
definitions of +, -, *, sqrt, /).
3) Where IEEE 754 provides facilities not currently
available in Fortran, provide them (e.g., ability to
detect and set NaN, +Inf, -Inf, etc.)
Sophisticated users are not satisfied with assertions that X+Y is
"mathematically" defined somehow. A very large fraction of
commercially available computers are IEEE 754 compliant (for some
meaning of the word compliant) but using IEEE 754 features from
Fortran currently results in non-portable programs. Improving
portability of programs is historically an important motivation for
Fortran standards efforts.
For most programs there will be no impact. For programs that were
written to some specific platform's IEEE 754 binding there may be
modest impact (depending on how the committee chooses to define the
standard binding).
For non-IEEE-754-based systems there will be no impact.
[ X3J3/93-162
][ ANSI/IEEE 754-1985, IEEE Standard for Binary Floating Point
Arithmetic
]
Keith H. Bierman, Keith.Bierman@eng.sun.com
| Nov 93, meeting 127:
| Tutorial presented. Straw vote to change the language regarding
| signed zeros and zero divided by zero (15-2-8). Straw vote to provide
| IEEE binding in: F95 | F2K | collateral standard | undecided
| (0-1-20-0).
Jul 93, WG5 meeting:
Removal of conflicts recommended by WG5 for 1995 revision (resolution
B9, item B2); investigation of full support in 1995 requested
(resolution B9, item C4)
May 93:
Proposal X3J3/93-162 prepared by Keith Bierman
----------------------------------------------------------------------
029
Interline Optimization
OPTIMIZATION, REORDER, BLOCKS
| Archival
----------------------------------------------------------------------
030
Variable Rank Arrays
ARRAY, RANK
Registered
|
1
Define a syntax that will allow Fortran arrays to have a rank which
can vary at run-time.
In effect, rank will be assumed much like shape currently can be. A
syntax something like:
SUBROUTINE XXX (A,B,C)
GENERIC DIMENSION A(:::::), B(:::::), C(:::::)
INTEGER TEMP (RANK(A))
TEMP = SHAPE(A)
A = B + C
END
would specify, for example, that arrays A, B, and C have from 1 to 5
dimensions. The A = B + C line requires that they all have the same
shape, but that requirement is not imposed by the dimension
statement.
The arrays could be used in array syntax statements where they would
have the natural meaning. If shape or rank are important an array
such as TEMP above could be used and element by element operations
could be driven by DO loops or whatever. We will need to relax some
of the distinctions between a scalar and an array of rank zero, so
that XXX could be called with all scalar arguments. We will also
need to invent some syntax that will allow array elements to be
referenced when the number of subscripts is not known. Perhaps
something like
A(%TEMP%) = 3
which, in the above example, would set the last element of the array
to 3.
It is difficult to define a derived type that can accept arrays as
operands. Defining an operator to operate on arrays of a defined
type requires defining about 22 different functions to account for
all of the cases of scalar .op. scalar, scalar .op. array, array
.op. scalar, and array .op. array and for ranks from
1 to 7. It will be worse if we allow arrays of higher rank (or
allow structure component selection to increase rank).
This should have no impact on existing programs. Compilers will
have to recognize additional syntax and be prepared to compile code
for an unknown rank array. It should make it easier to develop and
maintain modules which define and implement derived types.
Dick Hendrickson, hendrick@acset.be
May 93:
Proposal prepared by Dick Hendrickson
----------------------------------------------------------------------
031
| Varying Length Character with Declared Maximum
VARYING LENGTH, CHARACTER, MAXIMUM LENGTH
| X3J3 approved; ready for US TAG
| 1995 revision
1
Alternate proposal to X3J3/93-166
Fortran has a reputation for allowing users to code algorithms that
are readily optimizable. A varying length character type should be
added to the language that is consistent with this emphasis on
runtime performance. This new character type should provide the
flexibility of having varying length (e.g., the user does not have
to code the explicit deletion of trailing blanks when referencing a
variable of the new character type) and yet it should be possible to
code algorithms with this new type that are readily optimizable.
Thus the underlying implementation should not require extensive use
of dynamic storage. To achieve this, each definition of a variable
of this new character type could be required to specify a maximum
length. No further intrinsic routines would be needed. Existing
syntax for concatenation and substring could be used, with some
changes in the semantics.
A varying length character type allows the manipulation of text of
varying lengths without the algorithms having to track where the
text of interest ends and the trailing blanks begin. While ISO/N846
provides a varying length character type, a simpler definition would
meet the needs of most users without sacrificing runtime
performance. Those users that require the robustness of ISO/N846
could use that definition.
Allow a varying length, but require a maximum length also be
specified. The maximum length would be a specification expression
thus allowing constant and non-constant values.
CHARACTER, VARYING :: CHARVAR*10 ! varying length with a maximum
! size of 10
CHARVAR = 'A' ! No padding with trailing blanks
CHARVAR = CHARVAR // 'BC' ! Use of existing operator
No impact on existing code.
[ X3J3/93-173
][ X3J3/93-166
][ ISO/IEC JTC1/SC22/WG5-N846
]
X3J3
| Nov 93:
| Objection from J. Wagener to automatic US TAG approval.
| Nov 93, Meeting 127:
| Approved by X3J3 (12-7).
May 93, Meeting 125:
Proposal drafted by Janice Shepherd, X3J3/93-173.
----------------------------------------------------------------------
032
POSIX Binding to Fortran 90
POSIX, BINDING, FORTRAN 90, FORTRAN 77
Registered
|
1
Provide, in a separate, collateral standard, a binding for POSIX
that makes use of the new features of Fortran 90.
The existing POSIX binding to Fortran 77 is awkward and inefficient
to use due to the limitations of Fortran 77. New features of
Fortran 90, particularly modules and derived types, should make a
much more natural binding possible. Without such a binding, Fortran
(both 77 and 90) will remain a second class language on
POSIX-compliant systems.
Depending on how it is done, the Fortran 90 binding could cause
incompatibilities for Fortran codes that make use of the Fortran 77
binding. Implementers might have to support both the Fortran 77 and
Fortran 90 bindings.
[ POSIX Binding to Fortran 77
]
Len Moss, ljm@slac.stanford.edu, 415-926-3370
| Nov 93, meeting 127:
| Tutorial presented by Michael Hannah, chair of now disbanded POSIX.9
| working group. Straw vote on pursuing some sort of binding to POSIX.1
| and, possibly, a subset of POSIX.2 (8-5-9).
May 93:
Proposal drafted by Len Moss
----------------------------------------------------------------------
033
Object Oriented Fortran, OOF
OBJECT ORIENTED, OOF
Registered
|
1
Add an Object Oriented capability to Fortran, OOF. The requirements
listed below cannot be considered absolute. The X3J3 OOF
Subcommittee has done the work to define this initial set of OOF
capabilities. The set of language extensions (syntax and semantics)
required to accomplish these features needs to be defined. This
will be an iterative process since writing some code using the
features may dictate changes.
The OOF Subcommittee has defined the following requirements which
are divided into four groups:
Required for the 1995 draft,
Hoped for in the 1995 draft,
Some later draft, and
Guidelines.
I. In order to meet market demand, this group is required to be a
part of the 1995 draft.
A. Micro encapsulation (type definitions) and macro
encapsulation (modules).
B. Inheritance.
C. Constructors and destructors. There are two additional
points about this feature:
Are they optional or mandatory?
Does the constructor design also solve the
pointer initialization problem (requirement 013)?
II. This group of requirements would be nice to have in 1995 but
are not required for an initial implementation.
A. User Defined Polymorphism. The OOF user must be able to
define different method implementations for different data
types.
B. Abstract classes (i.e., the class has no instantiations)
and abstract methods (i.e., no implementation of the method
exists at the class level where the method is defined).
III. This last group of requirements has the least priority, they
may or may not become a part of the language, and they may not be
ready for the 1995 draft.
A. A carefully coded OOF library is applicable to all types,
e.g., a binary tree library would be applicable to all types.
Note: C++ templates.
B. OOF procedures may have an "inline" attribute.
C. Persistent objects.
D. Multiple inheritance.
IV. Guidelines.
A. If necessary, a subset should be accomplished for the 1995
draft, i.e., something should go into the 1995 draft.
B. Syntax and semantics must impose the OOF discipline.
C. The user of an OOF library must not require source.
D. Fortran is a performance oriented language, OOF must not
lose sight of this aspect of the language.
E. Both compile-time and run-time bindings.
F. Pointer and nonpointer (use local variables to create an
instance of a derived type) based objects.
G. Compile-time type checking where applicable.
H. Minimize the changes to Fortran.
The OOPs paradigm is of growing importance in the programming
community.
To be accomplished after WG5 authorization.
OOF must have the ability that a carefully coded library may be
extended by a programmer using inheritance.
[ OOF View Graphs, X3J3/93-068
][ Object Oriented Fortran, OOF, X3J3/93-120
][ OOF, Making your favorite language object-oriented, X3J3/93-141
]
X3J3 Object Oriented Subcommittee
Jul 93, WG5 meeting:
Investigation for 1995 revision requested (B9 Resolution, item C6)
May 93, Meeting 125:
Proposal for OOF requirement worked out; final draft submitted by
Tom Lahey.
Feb & May 93, Meetings 124 & 125:
OOF subcommittee held meetings and also arranged for well qualified
speakers to give OOPs seminars to the full committee.
Nov 92, Meeting 123:
X3J3 chartered the OOF Subcommittee (see X3J3/92-310).
----------------------------------------------------------------------
034
Variable Repeat Specifiers in Formats
FORMAT
Registered
|
1
The language should be capable of repeatable Format specifier [sic;
presumably proposer means variable repeat specifiers -- ed.]. For
example:
100 FORMAT(1X,N(F6.2,1X),2X,N2X)
110 FORMAT(10X,M(2X,'NO',2X))
where N and M are values defined somewhere in the program by
calculation, read, etc.
This capability exists in mainframe Fortran programs such as VAC
[sic; VAX? -- ed.] F77.
This capability would enable tables to be defined by read
statements, etc., and make the programs more flexible and easier to
write.
[ Letter from Gedeminas Reinis dated 6 Jun 93 (proposer's title:
"Repeatable Format Specifiers")
]
Gedeminas Reinis
56 Woodhaven Dr.
Rochester, New York
14625
| Nov 93, meeting 127:
| Straw vote to do: for F95 | for F2K | never | later (4-3-8-4).
| Motion to archive fails two-thirds vote (9-8).
14 Jun 93:
Proposal received.
----------------------------------------------------------------------
035
Specifying Default Precisions
DEFAULT REAL DOUBLE PRECISION KIND
Registered
|
1
Allow a user to specify the precision used for the 'default real'
and 'double precision real' types.
Under the current standard, each floating-point constant must
include a suffix specifying the "KIND" or precision, else the
interpretation defaults to the 'default real' type with
processor-dependent precision. By allowing the programmer to
specify the interpretation of 'default real' and/or 'double
precision real' in one location per program unit (rather than with
each of the individual occurrences of each literal constant) the
reliability, portability, and readability of codes could be
significantly improved.
Many compilers allow such a specification by compiler option. This
request is to make such functionality available in the language
itself in order to enforce the availability and interpretation of
the feature. (An alternative, of course, is to lobby vendors to
provide such a feature more uniformly).
For illustration purposes only:
IMPLICIT (REAL,KIND=SELECTED_REAL_KIND(10,30)) (DEFAULT)
The above would declare the 'default real' kind to be
processor-dependent type which allows 10 decimal digits and an
exponent range of at least 30. This would result in the selection
of a 64-bit floating-point representation on almost all computers in
current production, and is a verbose and indirect way of specifying
'default real' to be what most practitioners would prefer to refer
to as "REAL*8".
This would not invalidate any existing programs, however, some
significant difficulties with storage equivalence might occur if
'default real' and 'double precision real' were set to the same
"KIND". Storage equivalence between those types might have to be
disallowed in each program unit using this feature. This is already
the case with non-default "KIND"s so it should not be an
insurmountable difficulty.
[ Email from John D. McCalpin dated 5 Jul 93 (proposer's title:
"Specifying 'default real' and 'double precision real' precisions")
]
John D. McCalpin, mccalpin@perelandra.cms.udel.edu, 302-831-3686
| Nov 93, meeting 127:
| Straw vote to do: for F95 | for F2K | never | later (4-3-8-4).
| Motion to archive fails two-thirds vote (9-8).
5 Jul 93:
Proposal received.
----------------------------------------------------------------------
036
MAXLOC and MINLOC To Accept CHARACTER Arguments
MAXLOC MINLOC CHARACTER
Registered
|
1
Extend the ARRAY argument of the MAXLOC and MINLOC intrinsic
functions to accept arrays of type CHARACTER.
According to the Report of the 1993 WG5 meeting (Berchtesgaden),
X3J3 and WG5 have accepted minor changes to MAXLOC and MINLOC
intrinsics to simplify their use with one-dimensional arrays.
There is one other needed improvement in these functions, and it
would be a shame to bypass it while working on the other changes to
the same intrinsics. There seems to be no reason to prohibit
arguments of character data type to these functions.
Ranking, searching, and sorting of character arrays is almost as
important as for numeric arrays, although not quite so close to some
of Fortran's traditional applications. It should be made easy to
find the largest or smallest element in an array of character
strings.
Loren Meissner, meissner@lynx.cs.usfca.edu, 510-666-6328
15 Aug 93:
Proposal received.
----------------------------------------------------------------------
037
Argument Passing Mechanism
ARGUMENT ASSOCIATION
Registered
|
1
|
| See also pFR 048 (Improve Interoperability between Fortran and ANSI C)
|
It should be easy to call subroutines and functions written in other
languages, even if those procedures do not follow the language
independent calling standard. The new standard should allow the
user to specify how an actual argument is passed to a called
procedure, whether a function or subroutine, so that Fortran
programmers can easily access routines written in languages other
than Fortran. The user should be able to specify whether the
argument is passed by value, by reference, or by descriptor, and
also any other methods which may be commonly used in languages other
than Fortran. This capability would only apply to actual arguments,
not to dummy arguments of procedures written in Fortran.
The current Fortran standard requires tight association between
actual arguments and dummy arguments. Unfortunately for Fortran
programmers, the standards of other languages do not have this
requirement. Programmers who write subroutines and functions in
other languages often do not consider the needs of Fortran
programmers when they design or write their routines. The VMS
system services library and Microsoft Windows function library are
good examples. Since most operating system routines and library
routines are written in languages other than Fortran, a standard
method of specifying the argument passing mechanism will give
Fortran programmers access to these routines.
Fortran as it now exists does not have any method of providing this
functionality. If a particular processor does not have a
non-standard way of specifying argument passing mechanisms, then a
user either has to forgo using such library routines or else writing
special interface functions in a language other than Fortran.
Choosing the second course of action requires a programmer to have a
fairly sophisticated knowledge of systems programming techniques.
It also takes time and effort that could instead be spent on
developing the application.
Right now, many developers of Fortran language products provide this
capability. However, since there is no standard, there are
different and incompatible implementations from different vendors.
(Proposer's importance rating: 10)
One possible method of implementing this is the DEC Fortran method
of %VAL for value, %REF for reference, and %DESC for descriptor.
Another possible method is the Microsoft method.
Vendors of Fortran language products would have to rewrite their
Fortran syntax to provide this capability using the method approved
by the standard.
[ ISO/IEC 1539:1991 12.4.1.1, 14.6.1.1
]
Craig T. Dedo
17130 W. Burleigh Place
Brookfield, WI 53005
Phone: 414-783-5869,
Email: 72341.1171@compuserve.com
03 Nov 93:
Proposal received.
----------------------------------------------------------------------
038
Complete Set of Compiler Directives
COMPILER DIRECTIVES, CONDITIONAL COMPILATION,
PREPROCESSOR
Registered
|
1
Similar to some combination of pFR 015 (Conditional Compilation) and
pFR 026 (Directives)
The new Fortran standard should specify a complete set of compiler
directives that all standard conforming processors should recognize.
Right now, the INCLUDE directive is the only recognized compiler
directive. Compiler directives should support the following
capabilities:
- Specify whether INCLUDEd files are from a standard directory
or user directory. The definition of "standard directory" and
support for search paths for standard and user directories would be
processor dependent.
- Allow the definition and undefinition of compile-time
constants. Unlike C and C++, compile- time constants would only be
used in the compiler directives, NOT in the source code.
- Provide a Block-IF construct (IF-THEN-ELSEIF-ELSE-ENDIF)
capability. This would work just like the Block-IF construct in the
Fortran language itself, except that it would affect the compilation
process instead of the execution process.
- Allow the inclusion or suppression of line numbering.
- Allow the user to output error message into the listing file
if conditional testing produced error condition.
- Allow a developer of a Fortran processor to create
implementation specific directives without interfering with the
proper functioning of processors which do not support these
additional directives.
Although many of these ideas come from C and C++, any implementation
should have the look and feel of Fortran, not the look and feel of
C.
This requirement allows users to specify certain functionalities
which can only happen at compile time, not run time. These are
features which can only be supplied by compiler directives, not by
features that are already in the language. Right now, many
developers of Fortran language products provide this capability.
However, since there is no standard, there are different and
incompatible implementations from different vendors.
(Proposer's importance rating: 8)
This requirement may require developers of Fortran processors to
change the syntax of their existing compiler directives.
[ ISO/IEC 1539:1991 3.4
]
Craig T. Dedo
17130 W. Burleigh Place
Brookfield, WI 53005
Phone: 414-783-5869,
Email: 72341.1171@compuserve.com
03 Nov 93:
Proposal received.
----------------------------------------------------------------------
039
SYSTEM Command
OPERATING SYSTEM, SYSTEM COMMANDS, SUBPROCESS, USER EXIT
Registered
|
1
See also pFR 032 (POSIX binding to Fortran 90)
There should be a facility which allows the programmer to perform
operating system functions without leaving the program. This
feature is greatly increasing in popularity in application programs.
The facility should allow the programmer to have the option of
either performing one system command or else an indefinite series of
such operations.
This allows the application programmer to have a consistent way of
allowing the user to access operating system commands without
depending upon a particular processor's extensions and without
having to do system programming. This requirement requires direct
access to the operating system and usually requires the operating
system to spawn a subprocess (sometimes called a child process).
Right now, these capabilities are beyond the current definition of
the Fortran language.
Right now, some developers of Fortran language products provide this
capability. However, since there is no standard, there are
different and incompatible implementations from different vendors.
Having a standard method of providing this capability would reduce
the burden on application developers and increase the reliability of
applications when ported from one operating system to another.
(Proposer's importance rating: 6)
This could either be a command of the form SYSTEM [scalar-char-expr]
or else a subroutine which can be referenced in the form CALL SYSTEM
[scalar-char-expr]. If the CHARACTER expression is present and does
not evaluate to all blanks, the program would make a temporary exit
to the operating system and perform the operating system command
contained in the expression. If the CHARACTER expression is absent
or evaluates to all blanks, then the program would make a temporary
exit to the operating system for a series of commands to be input by
the user. This would continue until the user entered "EXIT" or some
other command that the operating system recognizes as instructing it
to exit back to the program.
Developers of processors which already have this type of capability
may have to change the syntax of their Fortran code which supplies
this capability.
Craig T. Dedo
17130 W. Burleigh Place
Brookfield, WI 53005
Phone: 414-783-5869,
Email: 72341.1171@compuserve.com
03 Nov 93:
Proposal received.
----------------------------------------------------------------------
040
Obtain the Command Line
COMMAND LINE, OPERATING SYSTEM
Registered
|
1
Similar to pFR 16 (Command Line Arguments and Environmental
Variables); see also pFR 032 (POSIX binding to Fortran 90)
The new standard should provide for a capability to obtain the
entire command line when the program starts up.
This feature allows application developers a way of passing
information to their program right at startup. Such information can
be very valuable in configuring the program before passing control
over to users or in performing other important tasks such as opening
documents and files. This requirement requires direct access to the
operating system. Right now, these capabilities are beyond the
current definition of the Fortran language.
Right now, some developers of Fortran language products provide this
capability. However, since there is no standard, there are
different and incompatible implementations from different vendors.
(Proposer's importance rating: 9)
This could be implemented by a subroutine reference of the form CALL
COMMAND_LINE (STARTUP_COMMAND). STARTUP_COMMAND would be scalar and
of type default character and contain the entire contents of the
command line which started the program, except for the program name.
If there was no command line available, the subroutine would return
all blanks. A windowed environment which has options that would
normally be included in a command-oriented command line would pass
in the options, including any files specified at startup. If there
were no such options or other information passed in, the windowing
environment would pass all blanks to STARTUP_COMMAND. Differences
in the length of the command line as provided by the operating
system and as given in the length specification for STARTUP_COMMAND
would be handled in the same way as CHARACTER information passed to
a CHARACTER variable in a READ statement, i.e. the command line
would be left justified and truncated or blank filled to the right
as necessary.
Vendors of Fortran language products would have to rewrite their
Fortran syntax to provide this capability using the method approved
by the standard.
Craig T. Dedo
17130 W. Burleigh Place
Brookfield, WI 53005
Phone: 414-783-5869,
Email: 72341.1171@compuserve.com
03 Nov 93:
Proposal received.
----------------------------------------------------------------------
041
Obtain Program Startup Command
COMMAND NAME, PATH, OPERATING SYSTEM
Registered
|
1
Related to pFR 16 (Command Line Arguments and Environmental
Variables) and pFR 40 (Obtain the Command Line); see also pFR 032
(POSIX binding to Fortran 90)
There should be a standard method of obtaining the startup command
which starts the program. This feature could be combined with the
feature titled, "Obtain the Command Line" [pFR 040].
This feature allows application developers to easily and reliably
obtain the fully qualified file specification of the application. A
program can then use this information in order to find related files
that it needs or for other purposes. This requirement requires
direct access to the operating system. Right now, these
capabilities are beyond the current definition of the Fortran
language.
Right now, some developers of Fortran language products provide this
capability. However, since there is no standard, there are
different and incompatible implementations from different vendors.
(Proposer's importance rating: 9)
This could be done in a subroutine reference of the form CALL
PROGRAM_STARTUP (STARTUP_COMMAND). STARTUP_COMMAND would be scalar
and of type default character and contain the command which started
the program, i.e. the program name fully qualified by any device,
directory, path, etc. If there was no startup command available,
the subroutine would return all blanks. A windowed environment
which has options that would normally be included in a
command-oriented startup command would pass in the command for the
actual executable, not the file reference for a configuration file.
For example, in Microsoft Windows, the startup command would be the
fully qualified file specification of the *.EXE file, not the file
specification for a *.PIF file. Differences in the length of the
command line as provided by the operating system and as given in the
length specification for STARTUP_COMMAND would be handled in the
same way as CHARACTER information passed to a CHARACTER variable in
a READ statement, i.e. the command line would be left justified and
truncated or blank filled to the right as necessary.
Vendors of Fortran language products would have to rewrite their
Fortran syntax to provide this capability using the method approved
by the standard.
Craig T. Dedo
17130 W. Burleigh Place
Brookfield, WI 53005
Phone: 414-783-5869,
Email: 72341.1171@compuserve.com
03 Nov 93:
Proposal received.
----------------------------------------------------------------------
042
Indexed Files
I/O, INDEXED FILES, KEYED ACCESS
Registered
|
1
The new standard should require the support of indexed files and
provide for standard access to indexed files.
Many applications require the orderly searching of files by the
value of one or more of the fields in the files. Neither sequential
access nor direct access allows for the reading or writing of
records by the key values of the records. The only way to implement
this now is to either use a separately purchased library of
subroutines or to develop the capability. The inclusion of this
capability will allow the user to concentrate on developing the
application rather than spending time and effort developing file
access mechanisms. It will allow the application developer to avoid
having to use complex searching and sorting algorithms in order to
access information based on field values. Finally, it allows
application developers to construct applications in a more
straightforward and intuitive manner, programming in the problem
domain rather than the computer science domain.
Right now, Fortran does not have any capability for reading or
writing records using values of the fields in the records. This
cannot be simulated using either sequential or direct access.
Some developers of Fortran language products provide this
capability. However, since there is no standard, there are
different and incompatible implementations from different vendors.
Having a standard method of providing this capability would reduce
the burden on application developers and increase the reliability of
applications when ported from one operating system to another.
Indexed file systems are powerful and useful enough of a feature so
that their availability in a Fortran processor should be assured by
being required by the standard.
(Proposer's importance rating: 10)
The best model to use is the implementation in DEC Fortran.
Following is a brief explanation of the needed keywords which are
required in order to implement this capability.
OPEN (ACCESS = "INDEXED")
This would specify access by one of the indexing keys, rather than
sequential or direct access. Indexed files could be accessed
sequentially but access in this manner would require use of ACCESS =
"SEQUENTIAL".
OPEN (KEY = (n:e1:e2[:type[:dir]], ...)
This keyword specifies the key(s) used in the file. The maximum
number of keys for a file would be at least 256, numbered from 0 to
255. Each key number must be unique. Key 0 is the primary key,
must be unique, and must be specified when the file is created.
Keys numbered 1 through the allowed maximum are alternate keys and
can have duplicate values. Each key can be any length from 1 byte
up to the maximum key length, which must be at least 255 bytes. For
each key, the first byte position must be at least 1 and the last
byte position must not exceed the length of the record. Following
are the specifications for each key:
n Key number, from 0 to at least 255
e1 Beginning byte position in the record for the specified key
e2 Ending byte position in the record for the specified key
type Data type of the key. The implementation must support all
kinds of INTEGER, REAL or CHARACTER data types which are
defined for the given processor. The implementation must
also support keys of defined data types which consist only
of fields of the above types. This last requirement would
allow for the support of composite keys, where the joining
of two or more fields can produce a unique key value.
dir Direction of the key, either ASCENDING or DESCENDING.
The KEY= keyword is optional for opening existing files but is
require d for creating files. If the KEY keyword is specified for
an existing file, it must agree with the existing keys for the file,
otherwise an error occurs.
READ (UNIT=io-unit, keyspec=keyvalue, KEYID=scalar-int-expr)
WRITE (UNIT=io-unit, keyspec=keyvalue, KEYID=scalar-int-expr)
These keywords read from or write to the specified io-unit using the
value of the key to find the record according to the rule specified
by keyspec. Keyspec must have one of the following values:
KEYEQ or KEY== Specifies that the key must exactly match
keyvalue.
KEYGE or KEY>= Specifies that the key must be greater than
or equal to keyvalue.
KEYGT or KEY> Specifies that the key must be greater than
keyvalue.
KEYLE or KEY<= Specifies that the key must be less than or
equal to keyvalue.
KEYLT or KEY< Specifies that the key must be less than
keyvalue.
KEYNEXT= Specifies the next keyvalue that exists for
the specified key, whether or not the value
of the specified key matches keyvalue.
KEYNEXTNE Specifies the next keyvalue that does not
or KEYNEXT/= match the current value of the specified
key.
The keyvalue must be a scalar expression of the same data type,
kind, and length as was defined for the key when the file was
created. The scalar expression must be either a constant or
variable. It cannot be an expression consisting of scalar values
joined by operators.
KEYID=scalar-int-expr specifies the key number of the key which is
being used for the read or write operation. The value of
scalar-int-expr must be between 0 and the maximum number of
alternate keys specified for the file. The KEYID expression must be
either a constant or variable.
Read and write operations can be performed using either formatted or
unformatted I/O.
INQUIRE (ACCESS=scalar-default-char-variable)
Allowed values would include INDEXED which would indicate that the
unit or file is connected for indexed file access.
INQUIRE (INDEXED=scalar-default-char-variable)
This is assigned the value YES if INDEXED is included in the allowed
set of allowed access methods for the file, NO if INDEXED is not
included in the set of allowed access methods for this file, and
UNKNOWN if the processor is unable to determine whether or not
INDEXED is included in the set of allowed access methods for the
file.
Vendors of Fortran language products would have to rewrite their
Fortran syntax to provide this capability using the method approved
by the standard.
[ ISO/IEC 1539:1991 9.2.1.2, 9.3.4.3, 9.4.1, 9.6.1
]
Craig T. Dedo
17130 W. Burleigh Place
Brookfield, WI 53005
Phone: 414-783-5869,
Email: 72341.1171@compuserve.com
03 Nov 93:
Proposal received.
----------------------------------------------------------------------
043
OOP Capabilities
OBJECT ORIENTED
Registered
|
1
Related to pFR 33 (Object Oriented Fortran, OOF)
The next Fortran standard should offer full support for object
oriented programming (OOP). The OOP implementation should include
support for abstraction, encapsulation, polymorphism, and
inheritance, as well as support of any other aspects of an OOP
implementation. A good model to use is the OOP support in the
Borland C++ 3.1 compiler. At a minimum, a new Fortran standard
should support all OOP features that this compiler supports.
OOP allows developers to construct software at a higher level of
abstraction than conventional methods do. Developers can work more
with real-world models than is possible with conventional methods.
OOP allows developers to construct software more in the problem
domain than in the computer science domain. Inheritance allows
developers to construct new classes which share common
characteristics with their parent classes.
Narrowly, the users who benefit are those who wish to use OOP in
their software development.
Broadly, all users of Fortran benefit. I believe that OOP is a
long-term trend, not a passing fad. Right now, C++ is very popular
and is gaining in popularity. In the near future (the next 5 to 7
years) OOP will be an expected feature of any modern programming
language. If Fortran includes OOP, software developers will be more
inclined to consider Fortran as a development language, thereby
increasing the popularity of Fortran. If Fortran does not include
OOP in the next standard, developers will most likely turn away from
Fortran and use a language like C++ that includes OOP support.
The full support for modules in Fortran 90 is a major step toward
this feature. However, even the full use of the module facility
does not allow the software developer to implement object oriented
programming. Only a full implementation of OOP will give developers
this capability.
Considering the likely direction of language evolution in the next 5
- 7 years and the demand for OOP features, I firmly believe that OOP
is the single most important improvement that the 1995 Fortran
Standard must have. Implementing this feature should be X3J3's top
priority.
The inclusion of OOP capabilities is an intrinsic part of the
language definition. It cannot be implemented at any other level.
(Proposer's importance rating: 10)
This requirement has no impact on existing Fortran code. The cost
of providing this capability would probably be fairly high.
Craig T. Dedo
17130 W. Burleigh Place
Brookfield, WI 53005
Phone: 414-783-5869,
Email: 72341.1171@compuserve.com
03 Nov 93:
Proposal received.
----------------------------------------------------------------------
044
Unsigned INTEGER Data Type
DATA TYPE, UNSIGNED INTEGER
Registered
|
1
The next Fortran standard should require processors to offer full
support for unsigned integers as well as signed integers. This
support should be required for all types of integers, i.e. for every
signed type of integer, there should be an unsigned type.
Many systems libraries (e.g. Microsoft Windows) are written in
other languages and require the use of unsigned integers as
arguments to certain functions and subroutines. The availability of
unsigned integers will make the interface to these functions and
subroutines much more straightforward than it is now. Also, for
some types of variables, there is no need for negative values. This
feature could also make Fortran more attractive as a development
language for systems programmers.
Specification of intrinsic data types is a feature that is
inherently part of the definition of a programming language. Since
there is no standard, there could be different and incompatible
implementations from different vendors.
(Proposer's importance rating: 9)
This could be implemented either by having an UNSIGNED keyword
immediately prior to the keyword INTEGER in the data type
declaration or by using KIND numbers. Possibly all that is needed
is a change in the wording of 4.3.1.1 to require representation of
both signed and unsigned integers.
This requirement has no impact on existing Fortran code. The
implementation costs should be quite low, especially since this
feature is part of most other programming languages.
[ ISO/IEC 1539:1991 4.3.1.1
]
Craig T. Dedo
17130 W. Burleigh Place
Brookfield, WI 53005
Phone: 414-783-5869,
Email: 72341.1171@compuserve.com
03 Nov 93:
Proposal received.
----------------------------------------------------------------------
045
Unicode Character Set Support
UNICODE, CHARACTER SET
Registered
|
1
The new Fortran standard should require support for the Unicode
character set.
Unicode is a new international standard which is starting to gain
popularity. The newly released Windows NT operating system supports
Unicode. Most likely, Unicode will be a major influence in the
development of software during the life of the next standard.
Any user who works in an environment that has Unicode support will
benefit from this feature.
Support for character sets is inherently part of the language
definition. Since there is no standard, there could be different
and incompatible implementations from different vendors.
(Proposer's importance rating: 10)
This requirement has no impact on existing Fortran code. I would
expect implementation cost to be minimal.
[ ISO/IEC 1539:1991 4.3.2.1
]
Craig T. Dedo
17130 W. Burleigh Place
Brookfield, WI 53005
Phone: 414-783-5869,
Email: 72341.1171@compuserve.com
03 Nov 93:
Proposal received.
----------------------------------------------------------------------
046
Row Major Arrays
ARRAYS, SUBSCRIPT ORDER, ROW-MAJOR
Registered
|
1
The new Fortran standard should provide support for defining arrays
as row-major as well as the current column-major approach. With
this attribute, an array would have the last dimension vary most
frequently rather than having the first dimension vary most
frequently.
Most other languages use row-major array storage. If a Fortran
program needs to pass an array to a routine written in another
language, there are usually major problems due to differing storage
arrangements. In addition, row-major storage is usually a much more
intuitive and natural method of arranging elements in the minds of
most people. The first index represents the primary (or most
important) division, the second index represents the next most
important, etc. Except for matrices, I doubt that the efficiency of
most programs would be affected.
(Proposer's importance rating: 8)
This could be done by defining a ROW_MAJOR keyword which would
declare an array to have row-major storage allocation.
This requirement has no impact on existing Fortran code.
Column-major arrays would still be supported.
[ ISO/IEC 1539:1991 6.2.2.2
]
Craig T. Dedo
17130 W. Burleigh Place
Brookfield, WI 53005
Phone: 414-783-5869,
Email: 72341.1171@compuserve.com
03 Nov 93:
Proposal received.
----------------------------------------------------------------------
047
File Sharing Modes
I/O, SHARED ACCESS
Registered
|
1
The new standard should allow for the specification of file sharing
modes. The file sharing specifier should allow the programmer to
specify any of the four sharing modes:
- Exclusive use by this unit
- Reading by others, but not writing
- Writing by others but not reading
- Permit full access by others
Currently, there is no facility for file sharing in the Fortran
standard. Some processors already provide this capability but there
are widely varying implementations. Some implementations do not
allow specification of all four sharing modes. The ability to
specify file sharing modes would allow Fortran developers to support
frequently accessed multi-user data bases on time-sharing systems or
local area networks. With the growing complexity of software and
the growing numbers of networked desktop PCs, there will be a large
demand for simultaneous access to complex data bases.
(Proposer's importance rating: 9)
The best method would be to allow for a second specification in the
character expression that follows the ACTION= keyword, in the same
manner that Lahey Fortran does. In the character expression, the
access mode specifier and sharing mode specifier would be separated
by a comma. Either one could come first. The sharing mode
specifier could have one of these four values, with the indicated
actions:
Sharing Mode Keywords Action
DENYBOTH For exclusive use by this unit in this
process
DENYWRITE Allows reading by others, but not writing
DENYREAD Allows writing by others, but not reading
DENYNONE Allows others to open the file for both
reading or writing
There should be no impact on exiting codes. Processors which
already provide this capability in a non-standard manner will have
to develop the support for the standard syntax.
[ ISO/IEC 1539:1991 9.3.4.8
]
Craig T. Dedo
17130 W. Burleigh Place
Brookfield, WI 53005
Phone: 414-783-5869,
Email: 72341.1171@compuserve.com
03 Nov 93:
Proposal received.
----------------------------------------------------------------------
|
| 048
| Improve Interoperability between Fortran and ANSI C
| INTERFACE, INTEROPERABILITY, ANSI C
| Registered
|
| 1
|
| Counter proposal to pFR 037 (Argument Passing Mechanism)
|
|
| It should be easy for procedures written in Fortran to call
| routines written in ANSI C. The Fortran standard should provide
| methods for specifying the names, data types, argument passing
| mechanisms, and returned results needed to communicate with ANSI
| C code.
|
|
| Many popular standards and libraries are specified with interfaces
| written in ANSI C. Because of differences between Fortran and
| ANSI C concerning, for example, routine calling methods,
| compatible data and argument passing mechanisms, Fortran users
| either can not easily use such interfaces or have to use bindings
| to such interfaces which are awkward, slow, or incomplete.
| Direct access to such interfaces from Fortran would make these
| interface more readily available.
|
|
| Stan Whitlock for X3J3/JOR.
|
|
|
| Nov 93, meeting 127:
| Proposal drafted.
|
|
|
----------------------------------------------------------------------