#######################################################################
# #
# X3J3/93-004r4 #
# Journal Of Requirements #
# #
# Oct 1993 #
# #
#######################################################################
Status Number Title
A 000001 Bit Data Type, Non-string
R 000002 Variant Derived Type
R 000003 Array Components of Array Structures
Xa 000004 FORALL
A 000005 DIAGONAL Function
A 000006 PROJECT Function
A 000007 REPLICATE Function
A 000008 RANK Intrinsic Function
A 000009 FIRSTLOC and LASTLOC intrinsics
R 000010 Nesting of Internal Procedures
A 000011 Internal Procedure Names as Actual Arguments
Xb 000012 Condition Handling
R 000013 Pointer Initialization
C 000014 Language Management
Xa 000015 Conditional Compilation
Xa 000016 Command Line Arguments and Environmental Variables
Xb 000017 Bit Data Type, String
Xb 000018 Controlling Pointer Bounds
R 000019 Variant Derived Type, Untagged
R 000020 User Defined Elemental Functions
R 000021 Obsolesce Fixed Source Form
R 000022 Keep It Simple, Make It Fine
R 000023 User Defined Intrinsic Functions
R 000024 Nested WHERE Statements
R 000025 Pure User Functions and Subroutines
R 000026 Directives
R 000027 Packaging Implementer Specific Intrinsics in MODULEs
R 000028 Binding to IEEE 754
R 000029 Interline Optimization
R 000030 Variable Rank Arrays
R 000031 Efficient Varying Length Character Type
R 000032 POSIX Binding to Fortran 90
R 000033 Object Oriented Fortran, OOF
R 000034 Variable Repeat Specifiers in Formats
R 000035 Specifying Default Precisions
| R 000036 MAXLOC and MINLOC To Accept CHARACTER Arguments
INTRODUCTION
This document is an internal working document of X3J3, the Fortran
Technical Committee of the American National Standards Association,
and contains proposed requirements for future revisions of the
Fortran standard. This is an evolving document, and it is expected
that more requirements will be added.
The status of each item in this document is tracked with the STATUS
field, the values of which are:
R. Registered
Received and assigned a number by the requirements editor, and
incorporated into the next revision of this standing document.
C. X3J3 consideration in progress
Put on the table for active consideration by X3J3; requires a
majority vote of the committee.
Xa. X3J3 approved; ready for WG5 (1995 revision)
Xb. X3J3 approved; ready for WG5 (2000 revision)
Submitted to WG5, with the indicated recommendation for the
| target revision cycle, by a majority vote of X3J3.
S. Satisfied
Substantially satisfied in a new revision of the Fortran, or a
related, standard, as determined by a two-thirds vote of X3J3.
| F. Failed WG5 approval
Failed to gain approval by WG5 after forwarding from X3J3. This
status is equivalent to "X3J3 consideration in progress".
A. Archival
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
1
Grandfather requirement from old Appendix F
Add an intrinsic bit data type to Fortran with the following
characteristics.
Bit is a nonnumeric intrinsic type that has two values. Named
objects may be declared to be of type bit and literal constants of
type bit are allowed. Intrinsic operations and functions are
provided for objects of this type. Bit objects may appear in
expressions and may be used to mask arrays. Bit expressions can
appear in control constructs. Input and output is provided for bit
objects.
[To be supplied; requirement "grandfathered".]
The following is a suggested implementation [note that this
implementation is based on a preliminary draft of Fortran 90 and
will need to be revised].
Bit Constant
Rule R306 for literal constants must be extended to include a bit
constant.
literal-constant int-literal-constant
real-literal-constant
complex-literal-constant
logical-literal-constant
char-literal-constant
boz-literal-constant
bit-literal-constant
Bit Operators
Rule R310 for intrinsic operators must be extended to include bit
operators.
intrinsic-operator power-op
mult-op
add-op
bnot-op
band-op
bor-op
concat-op
rel-op
not-op
and-op
or-op
equiv-op
bnot-op .BNOT.>
band-op .BAND.>
bor-op .BOR.>
.BXOR.>
Bit Type
The bit type> has two values which represent the bit
values zero and one. Each of these values has two literal
representations.
bit-literal-constant B'0'>
B'I'>
B"0">
B"1">
The values B'0' and B"0" are the same and similarly the values B'1'
and B"1" are the same. The intrinsic operations defined for data
objects of bit type are: bit negation (.BNOT.), bit conjunction
(.BAND.),bit inclusive disjunction (.BOR.), and bit exclusive
disjunction (.BXOR.). These operations are defined in F.1.1.5.10.
Bit masked array assignment is defined in F.1.1.6.1 and F.1.1.6.2.
The type specifier for the bit type is the keyword BIT.
Bit Declaration Statement
A bit object may have rank and shape. There are no additional
attributes for objects of type bit. Rule R502 must be extended to
include a BIT declaration.
type-spec INTEGER> [ kind-selector ]
REAL> [ kind-selector ]
DOUBLE PRECISION>
COMPLEX> [ kind-selector ]
CHARACTER> [ char-selector ]
LOGICAL> [ kind-selector ]
BIT>
TYPE> ( type-name )
The BIT type specifier specifies that all objects whose names are
declared in this statement are of intrinsic type bit.
An equivalence-object> must not be the name of an object of
bit type.
A common-block-object> must not be the name of an object of
bit type.
The variables or arrays whose names are included in the data-i-
do-object-list> must not be of type bit.
Bit Expressions
Bit Objects in Expressions
To include bit expressions, an additional category of expressions
is required.
These categories are related to the different operator precedence
levels and, in general, are defined in terms of other categories.
The simplest form of each expression category is a primary>.
The rules given below specify the syntax of an expression. For
convenience, the low-level operator construction rules, but not the
constraints, have been duplicated below from Section 3 where
appropriate. See 3.2.4 for the constraints on defined-unary-
op> and defined-binary-op>. The semantics are specified in
7.1.3 and 7.1.7.
Primary
primary constant
variable
array-constructor
structure-constructor
function-reference
( expr )
Examples of a primary> are:
Example Syntactic Class
=======================================================
1.0 constant>
A variable>
[1.0,2.0] array-constructor>
PERSON('Jones', 12) structure-constructor>
F(X,Y) function-reference>
(S+T) (expr>)
Level-1 Expressions
Defined unary operators have the highest operator precedence (Table
F.1). Level-1 expressions are primaries optionally operated on by
defined unary operators:
level-1-expr [ defined-unary-op ] primary
defined-unary-op .> letter [ letter ]...
.>
Simple examples of a level-1-expr> are:
Example Syntactic Class
==========================================
A primary
.INVERSE. B level-1-expr
A more complicated example of a level-1 expression is:
.INVERSE. (A + B)
Level-2 Expressions
Level-2 expressions are level-1 expressions optionally involving
the numeric operators power-op>, mult-op>, and add-
op>.
mult-operand level-1-expr [ power-op mult-operand ]
add-operand [ add-operand mult-op ] mult-operand
level-2-expr [ add-op ] add-operand
level-2-expr add-op add-operand
power-op **
mult-op *
/
add-op +
-
Simple examples of a level-2 expression are:
Example Syntactic Class
==========================================
A level-1-expr
B ** C mult-operand
D * E add-operand
F - I level-2-expr
+1 level-2-expr
A more complicated example of a level-2 expression is:
- A + D * E + B ** C
Level-3 Expressions
Level-3 expressions are level-2 expressions optionally involving
the bit operators bnot-op>, band-op>, and bor-
op>.
band-operand [ bnot-op ] level-2-expr
bor-operand [ bor-operand band-op ] band-operand
level-3-expr [ level-3-expr bor-op ] bor-operand
bnot-op .BNOT.>
band-op .BAND.>
bor-op .BOR.>
.BXOR.>
Simple examples of a level-3 expression are:
Example Syntactic Class
==========================================
A level-2-expr
.BNOT. B band-operand
C .BAND. D bor-operand
E .BOR. F level-3-expr
G .BXOR. H level-3-expr
A more complicated example of a level-3 expression is:
A .BXOR. B .BAND. .BNOT. C
Level-4 Expressions
Level-4 expressions are level-3 expressions optionally involving
the character operator concat-op>.
level-4-expr [ level-4-expr concat-op ] level-3-expr
concat-op //
Simple examples of a level-4 expression are:
Example Syntactic Class
==========================================
A level-3-expr
B // C level-4-expr
A more complicated example of a level-4 expression is:
X // Y // 'ABCD'
Level-5 Expressions
Level-5 expressions are level-4 expressions optionally involving
the relational operators rel-op>.
level-5-expr [ level-4-expr rel-op ] level-4-
expr
rel-op .EQ.>
.NE.>
.LT.>
.LE.>
.GT.>
.GE.>
==
/=
<
<=
>
>=
Simple examples of a level-5 expression are:
Example Syntactic Class
==========================================
A level-4-expr
B .EQ. C level-5-expr
D < E level-5-expr
A more complicated example of a level-5 expression is:
(A + B) .NE. C
Level-6 Expressions
Level-6 expressions are level-5 expressions optionally involving
the logical operators not-op>, and-op>, or-op>,
and equiv-op>.
and-operand [ not-op ] level-5-expr
or-operand [ or-operand and-op ] and-operand
equiv-operand [ equiv-operand or-op ] or-operand
level-6-expr [ level-6-expr equiv-op ] equiv-operand
not-op .NOT.>
and-op .AND.>
or-op .OR.>
equiv-op .EQV.>9
.NEQV.>
Simple examples of a level-6 expression are:
Example Syntactic Class
==========================================
A level-5-expr
.NOT. B and-operand
C .AND. D or-operand
E .OR. F equiv-operand
G .EQV. H level-6-expr
S .NEQV. T level-6-expr
A more complicated example of a level-6 expression is:
A .AND. B .EQV. .NOT. C
A bit intrinsic operation>, character intrinsic
operation>, relational intrinsic operation>, and
logical intrinsic operation> are similarly defined in
terms of a bit intrinsic operator> (.BAND., .BOR., .BXOR.,
and .BNOT.), character intrinsic operator> (//),
relational intrinsic operator> (.EQ., .NE., .GT., .GE., .LT.,
.LE., ==, <>, >, >=, <, and <=), and logical intrinsic
operator> (.AND., .OR., .NOT., .EQV., and .NEQV.), respectively.
A bit relational intrinsic operation> is a relational
intrinsic operation where the operands are of type bit and the
operator is .EQ., .NE., ==, or <>.
Type of Operands and Result for the Intrinsic Operation
[x>_1] op x>_2. (The symbols I, R, Z, B, C, and L stand
for the types integer, real, complex, bit, character, and logical,
respectively. Where more than one type for x_2 is given, the type
of the result of the operation is given in the same relative
position in the next column.)
Intrinsic Operator Type of Type of Type of
op x1 x2 [x1] op x2
==========================================================
unary +, - I, R, Z I, R, Z
----------------------------------------------------------
binary +, -, I I, R, Z I, R, Z
*, /, ** R I, R, Z R, R, Z
Z I, R, Z Z, Z, Z
----------------------------------------------------------
.BNOT. B B
----------------------------------------------------------
.BAND., .BOR. B B B
.BXOR.
----------------------------------------------------------
// C C C
----------------------------------------------------------
.EQ., .NE., ==, /= I I, R, Z L, L, L
R I, R, Z L, L, L
Z I, R, Z L, L, L
C C L
B B L
----------------------------------------------------------
.GT., .GE., I I, R L, L
.LT., .LE. R I, R L, L
>, >=, <, <= C C L
B B L
----------------------------------------------------------
.NOT. L L
----------------------------------------------------------
.AND., .OR., L L L
.EQV., .NEQV.
Evaluation of Bit Intrinsic Operations
The rules given in F.1.1.5.10 specify the interpretation of bit
intrinsic operations. Once the interpretation of an expression has
been established in accordance with those rules, the processor may
evaluate any other expression that is bit-wise equivalent, provided
that the integrity of parentheses is not violated. For example, for
variables B1, B2, and B3 of type bit,the processor may choose to
evaluate the expression
B1 .BOR. B2 .BOR. B3
as
B1 .BOR. (B2 .BOR. B3)
Two expressions of type bit are bit-wise equivalent if their values
are equal for all possible values of their primaries.
Bit Intrinsic Operations
A bit operation is used to express a bit computation. Evaluation of
a bit operation produces a result of type bit, with a value of B'0'
or B'1'. A bit operand may have rank and shape. The bit operators
and their interpretation when used to form an expression are given
in Table F.2, where x_1 denotes the operand to the left of the
operator and x_2 denotes the operand to the right of the operator.
Interpretation of the Bit Intrinsic Operators.
Use of
Operator Representing Operator Interpretation
===============================================================
.BNOT. Bit Negation .BNOT.x2 Bit negation of x2
.BAND. Bit Conjunction x1.BAND.x2 Bit conjunction of
x1 and x2
.BOR. Bit Inclusive x1.BOR.x2 Bit inclusive
Disjunction disjunction of
x1 and x2
.BXOR. Bit Exclusive x1.BXOR.x2 Bit exclusive
Disjunction disjunction of
x1 and x2
The values of bit intrinsic operations are shown in Table F.3.
The Values of Operations Involving Bit Intrinsic Operators
x1 x2 .BNOT.x2 x1.BAND.x2 x1.BOR.x2 x1.BXOR.x2
===================================================================
B'1' B'1' B'0' B'1' B'1' B'0'
B'1' B'0' B'1' B'0' B'1' B'1'
B'0' B'1' B'0' B'0' B'1' B'1'
B'0' B'0' B'1' B'0' B'0' B'0'
Derived-type operands may contain bit components.
Precedence of Bit Operators
There is a precedence among the intrinsic and extension operations
implied by the general form in 7.1.1, which determines the order in
which the operands are combined, unless the order is changed by the
use of parentheses. This precedence order is summarized in Table
.
Categories of Operations and Relative Precedences.
Category
of Operation Operators Precedence
===========================================================
Extension defined-unary-op> Highest
Numeric ** .
Numeric * or / .
Numeric unary + or \- .
Numeric binary + or \- .
Bit .BNOT. .
Bit .BAND. .
Bit .BOR. or .BXOR. .
Character // .
Relational .EQ., .NE., .LT., .
.LE., .GT., .GE.
==,<>, <, <=, >, >=
Logical .NOT. .
Logical .AND. .
Logical .OR. .
Logical .EQV. or .NEQV. .
Extension defined-binary-op> Lowest
The precedence of a defined operation is that of its operator,
whether it is an overloaded intrinsic operator or an extension
operator.
Array Mask Expressions of Type Bit
The value of a bit array expression may be used to mask the
evaluation of expressions and assignment of values in array
assignment statements.
General Form of the Masked Array Assignment
A masked array assignment is either a WHERE statement or
WHERE construct.
where-stmt WHERE> ( mask-expr )
assignment-stmt
where-construct where-construct-stmt
[ assignment-stmt ]...
[ elsewhere-stmt
[ assignment-stmt ]... ]
end-where-stmt
where-construct-stmt WHERE> ( mask-expr )
mask-expr logical-expr
bit-expr
elsewhere-stmt ELSEWHERE>
end-where-stmt END WHERE>
The shape of the mask-expr> and the variable being defined in
each assignment-stmt> must be the same.
Examples of a masked array assignment are:
WHERE (BIT_ARRAY_TEMP) TEMP = TEMP - REDUCE_TEMP
WHERE (BIT_ARRAY_PRESSURE)
PRESSURE = PRESSURE + INC_PRESSURE
TEMP = TEMP - 5.0
END WHERE
Interpretation of Masked Array Assignments
The execution of a masked array assignment causes the expression
mask-expr> to be evaluated.
The array assignment statements following the WHERE and ELSEWHERE
keywords are executed in normal execution sequence. An array may be
defined in more than one array assignment statement in a WHERE
construct. A reference to an array may appear subsequent to its
definition in the same WHERE construct.
When an assignment-stmt> is executed in a masked array
assignment, the expr> in the where-stmt> or each
expr> in the array assignment statements, immediately
following the WHERE keyword, is evaluated for all elements where
mask-expr> is true (or for all elements where mask-
expr> is false in the array assignment statements following
ELSEWHERE), and the result is assigned to the corresponding
elements of variable>. For each false value of mask-
expr> (or true value for the array assignment statements after
ELSEWHERE) the value of the corresponding element of
variable> in each array assignment statement immediately
following the WHERE keyword is not affected, and it is as if the
expression expr> were not evaluated. If a mask-expr> is
of type BIT, the elements with value B'1' are treated as true and
elements with value B'0' are treated as false.
If a transformational function reference occurs in expr>, it
is evaluated without any masked control by the mask-expr>;
that is, all of its argument expressions are fully evaluated and
the function is fully evaluated. Elements corresponding to true
values in mask-expr> (false in the expr> after
ELSEWHERE) are selected for use in evaluating each expr>.
In a masked array assignment, only a WHERE statement may be a
branch target. Changes to entities in mask-expr> do not
affect the execution of statements in the masked array assignment.
Execution of an END WHERE has no effect.
Bit Expressions in Control Constructs
IF Construct
If the scalar mask expression is of type BIT, an expression with
value B'1' is treated as true and an expression with value B'0' is
treated as false.
IF Statement
If the scalar mask expression is of type BIT, an expression with
value B'1' is treated as true and an expression with value B'0' is
treated as false.
CASE Construct
A case expression may be a scalar bit expression. Rule R812 must be
extended.
case-expr scalar-int-expr
scalar-char-expr
scalar-logical-expr
scalar-bit-expr
A corresponding case value in a case selector may be a scalar bit
constant expression. Rule R815 must be extended.
case-value-range case-value
case-value :
: case-value
case-value : case-value
case-value scalar-int-constant-expr
scalar-char-constant-expr
scalar-logical-constant-expr
scalar-bit-constant-expr
If the case value range is of the form low>: or :high>,
the data type must not be bit.
Bit Input/Output Editing
Bit Edit Descriptor
There is a bit edit descriptor: B. Rule R1005 must be extended.
data-edit-desc I> w [ . m ]
F> w . d
E> w . d [ E> e ]
EN> w . d [ E> e ]
G> w . d [ E> e ]
B> w
L> w
A> [ w ]
D> w . d
B Editing
The Bw> edit descriptor indicates that the field occupies
w> positions. The specified input/output list item must be of
type bit.
The input field consists of w>- 1 blanks and either a 0 or a
1, in any order. The output field consists of w>- 1 blanks
followed by either a 0 or a 1. The specifiers BZ and BN have no
effect on bit editing.
List-Directed and Namelist Output
The form of the bit output constant produced for the value B'1' is
1. The form of the bit output constant produced for the value B'0'
is 0.
Bit Functions
The elemental functions LBIT and BITL convert between bit and
logical type. The transformational functions IBITLR and BITLR
convert between a bit array and an integer, counting bits from left
to right; IBITRL and BITRL are similar functions that count bits
from right to left.
The inquiry function MAXBITS returns the maximum size of a bit
array that can be converted to an integer.
BITL (L) Convert from logical to bit type
BITLR (I, SIZE) Convert an integer to a bit array,
Optional SIZE counting left to right
BITRL (I, SIZE) Convert an integer to a bit array,
Optional SIZE counting right to left
IBITLR (B) Convert a bit array to an integer,
counting left to right
IBITRL (B) Convert a bit array to an integer,
counting right to left
LBIT (B) Convert from bit to logical type
MAXBITS (I) Maximum bit array length for
conversion
BITL (L)
Convert logical to bit type.
Elemental function.
L must be of type logical.
Bit.
The result has the value B'1' if L has the value
.TRUE. and the value B'0' if L has the value .FALSE.
BITL (.TRUE.) has the value B'1'.
BITLR (I, SIZE)
SIZE
Convert an integer to a bit array, counting left to
right.
Transformational function.
I must be scalar and of type integer.
Its value must not be negative.
SIZE (optional) must be scalar and of type integer
with a positive value. If it is
omitted, it is as if it were present
with the value MAXBITS (1).
The result is a bit array of rank one with
SIZE number of elements.
The result is a bit array containing the binary
representation of the argument. The array element with the largest
subscript value will contain the least significant bit of the
binary representation. Zero extension or truncation will take place
at the low end of the array as necessary. IBITLR (BITLR (J)) must
have the value J for any nonnegative value of the integer J. BITLR
(IBITLR (B), SIZE = ESIZE (B)) must have the value B for any value
of a bit array B for which ESIZE (B) <= MAXBITS (1).
BITLR (5, 6) has the value [B'0', B'0', B'0', B'1', B'0',
B'1'].
BITRL (I, SIZE)
SIZE
Convert an integer to a bit array, counting right to
left.
Transformational function.
I must be scalar and of type integer.
Its value must not be negative.
SIZE (optional) must be scalar and of type integer
with a positive value. If it is
omitted, it is as if it were present
with the value MAXBITS (1).
The result is a bit array of rank one with
SIZE number of elements.
The result is a bit array containing the binary
representation of the argument. The array element with the largest
subscript value will contain the most significant bit of the binary
representation. Zero extension or truncation will take place at the
high end of the array as necessary. IBITRL (BITRL (J)) must have
the value J for any nonnegative value of the integer J. BITRL
(IBITRL (B), SIZE = ESIZE (B)) must have the value B for any value
of a bit array B for which ESIZE (B) <= MAXBITS (1).
BITRL (5, 6) has the value [B'1', B'0', B'1', B'0', B'0',
B'0'].
IBITLR (B)
Convert a bit array to an integer, counting left to
right.
Transformational function.
B must be of type bit and rank one. Its size must
satisfy the inequality ESIZE (B) <= MAXBITS (1).
Scalar integer.
The result has value equal to the integer
represented by the bits in the array B, regarded as a bit string
with the element having the largest subscript value being the least
significant bit of the result. IBITLR (BITLR (J)) must have the
value J for any nonnegative value of the integer J. BITLR (IBITLR
(B), SIZE = ESIZE (B)) must have the value B for any value of a bit
array B for which ESIZE (B) <= MAXBITS (1).
IBITLR ([B'0', B'1', B'0', B'1']) has the value 5.
IBITRL (B)
Convert a bit array to an integer, counting right to
left.
Transformational function.
B must be of type bit and rank one. Its size must
satisfy the inequality ESIZE (B) <= MAXBITS (1).
Scalar integer.
The result has value equal to the integer
represented by the bits in the array B, regarded as a bit string
with the element having the largest subscript value being the most
significant bit of the result. IBITRL (BITRL (J)) must have the
value J for any nonnegative value of the integer J. BITRL (IBITRL
(B), SIZE = ESIZE (B)) must have the value B for any value of a bit
array B for which ESIZE (B) <= MAXBITS (1).
IBITRL ([B'1', B'0', B'1', B'0']) has the value 5.
LBIT (B)
Convert bit to logical type.
Elemental function.
B must be of type bit.
Logical.
The result has the value .TRUE. if B has the value
B'1' and the value .FALSE. if B has the value B'0'.
LBIT (B'1') has the value .TRUE.
MAXBITS (I)
Returns the maximum size of a bit array that can be
converted to a value of type integer.
Inquiry function.
I must be of type integer.
Integer scalar.
The result has value equal to the maximum size of a
bit array B that can be converted to integer using IBITLR (B) or
IBITRL (B).
Bit Mask Argument
An argument named MASK for any intrinsic function (13.12, F.2.4)
may be of type bit. When the argument is of type bit, a B'1' value
is interpreted as true and a B'0' is interpreted as false. The
following intrinsic functions have MASK arguments that may be of
type bit: ALL, ANY, COUNT, FIRSTLOC, LASTLOC, MAXLOC, MAXVAL,
MERGE, MINLOC, MINVAL, PACK, PRODUCT, PROJECT, SUM, and UNPACK.
Bit Storage Sequence
A bit data object has no storage sequence.
[ X3J3/93-072
][ Section F.1.1 of S8.104 Appendix F (aka X3J3/119-LJM-1)
]
X3J3
May 93, meeting 125:
Status changed to Archival (UC).
Feb 93, meeting 124:
Status of Bit Data Type portion of S8.104 Appendix F material, as
reformatted by L. Moss in 93-072, changed to "X3J3 consideration in
progress" (15-2).
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).
-----------------------------------------------------------------------
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
X3J3 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
| Jul 93, WG5 meeting:
| 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
1
Grandfather requirement from old Appendix F
Add an intrinsic function to create a diagonal matrix from its
diagonal; that is, given an input vector of size n and of any type
and type parameters, return an array of the same type and type
parameters and of shape (/ n, n /), with the diagonal elements set
to the input vector and the off-diagonal elements to a fill value.
The fill value must be of the same type and type parameters as the
input vector, and may be specified by the second arguments or, for
intrinsic types, defaults to: zero for numeric types; false for
logical; and blanks for character.
[To be supplied if the STATUS is changed from "Registered" to "X3J3
consideration in progress". Requirement "grandfathered".]
[ Section F.2.4.1 of S8.104 Appendix F (aka X3J3/119-LJM-1)
]
X3J3
May 93, meeting 125:
Status changed to Archival (UC).
Apr 93:
Section F.2.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).
-----------------------------------------------------------------------
006
PROJECT Function
PROJECT, FUNCTION, ARRAY, MASK, FIELD, REDUCE RANK
Archival
1
Grandfather requirement from old Appendix F
Provide a function (called, for example, PROJECT) to "project out" a
scalar or a reduced-rank object from an input array, under the
control of a mask array.
PROJECT should have two forms. Both forms should take an input
array of any type and type parameters and any defined shape, a
logical mask array of the same shape, and a "field" (i.e., default)
object of the same type and type parameters as the input arrays.
Both forms return an object of the same type and type parameters as
the input array.
The first form of PROJECT returns a scalar value corresponding to
the single true value of the mask array, if any, or to the scalar
field value otherwise (note that the mask may have at most one true
value in this case).
In the second form, an additional argument is specified to identify
one of the dimensions of the input array along which to take the
"projection". In this case, both the field argument and the result
have a shape obtained from that of the input array by deleting the
extent along the specified dimension. The value of the result is
obtained by applying the first form of PROJECT to each rank-one
section along the specified dimension of the input array and mask,
with a field value obtained from the corresponding element of the
field array. In other words, if ARRAY, MASK, and FIELD are the
names of the input array, the mask, and the field, respectively, and
if "r" is the rank of ARRAY and "d" is the specified dimension, then
element
(s_1, ..., s_(d-1), s_(d+1), ..., s_r)
of the result is obtained by applying PROJECT to
ARRAY( s_1, ..., s_(d-1), :, s_(d+1), ..., s_r )
with mask
MASK( s_1, ..., s_(d-1), :, s_(d+1), ..., s_r )
and field value
FIELD( s_1, ..., s_(d-1), s_(d+1), ..., s_r ).
See section F.2.4.2 of S8.104 Appendix F for additional details.
[To be supplied if the STATUS is changed from "Registered" to "X3J3
consideration in progress". Requirement "grandfathered".]
[ Section F.2.4.2 of S8.104 Appendix F (aka X3J3/119-LJM-1)
]
X3J3
May 93, meeting 125:
Status changed to Archival (23-1).
Apr 93:
Section F.2.4.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).
-----------------------------------------------------------------------
007
REPLICATE Function
REPLICATE, FUNCTION, ARRAY
Archival
1
Grandfather requirement from old Appendix F
Add an intrinsic function to expand an array by replicating it a
number of times along a specified dimension. In other words, given
an input array of any type and type parameters, the result is an
array of the same type, type parameters, and rank, and a shape
obtained from that of the input array by multiplying the extent in
the specified dimensions by an integer number of copies (or by zero
if the number of copies is specified to be negative). The values of
any new elements are obtained from the original array by subtracting
an integral multiple of the origin extent in the specified dimension
from the corresponding subscript.
[To be supplied if the STATUS is changed from "Registered" to "X3J3
consideration in progress". Requirement "grandfathered".]
[ Section F.2.4.3 of S8.104 Appendix F (aka X3J3/119-LJM-1)
]
X3J3
May 93, meeting 125:
Status changed to Archival (UC).
Apr 93:
Section F.2.4.3 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).
-----------------------------------------------------------------------
008
RANK Intrinsic Function
RANK, INTRINSIC, INQUIRY FUNCTION
Archival
1
Grandfather requirement from old Appendix F
Return the rank of an array or a scalar where the
array or scalar may be of any type. The result is an integer
scalar: The result has the value zero if the argument is scalar and
otherwise has the value equal to the rank of the argument.
[To be supplied if the STATUS is changed from "Registered" to "X3J3
consideration in progress". Requirement "grandfathered".]
No impact on existing code.
[ Section F.2.4.4 of S8.104 Appendix F (aka X3J3/119-LJM-1)
]
X3J3
May 93, meeting 125:
Status changed to Archival (23-1).
Mar 93:
Section F.2.4.4 of S8.104 Appendix F material reformatted by
D. Mattoon.
Feb 93, meeting 124:
Vote to change the status of RANK Intrinsic portion of S8.104
Appendix F material to "Archival" fails two-thirds requirement
(11-4).
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).
-----------------------------------------------------------------------
009
FIRSTLOC and LASTLOC intrinsics
FIRSTLOC, LASTLOC, INTRINSIC
Archival
1
Grandfather requirement from old Appendix F
Locate the leading edges of the set of true elements of a logical
mask. Locate the trailing edges of the set of true values of a
logical mask.
[To be supplied if the STATUS is changed from "Registered" to "X3J3
consideration in progress". Requirement "grandfathered".]
FIRSTLOC(MASK,DIM)
LASTLOC(MASK,DIM)
MASK is a logical array. It must not be a scalar. Its shape must
be defined.
DIM (optional) must be an integer scalar with a value in the range
of 1 <= DIM <= n, where n is the rank of MASK.
The result is an array of the same shape as MASK and of the type of
MASK.
Case (i). No DIM argument. If MASK contains all false elements,
the result of both FIRSTLOC(MASK) and LASTLOC(MASK) is an array with
all the elements false. If MASK contains at least one true element,
the resulting array has a single true element with all other
elements false. For FIRSTLOC(MASK), the true element is in the
position corresponding to the first true element in array element
order in MASK. For LASTLOC(MASK), the true element is in the
position corresponding to the last true element in array element
order in MASK.
Case (ii). The result of FIRSTLOC(MASK,DIM) is defined by applying
FIRSTLOC to each of the one-dimensional array sections that lie
parallel to dimension DIM. The result of LASTLOC(MASK,DIM) is
defined by applying LASTLOC to each of the one-dimensional array
sections of MASK that lie parallel to dimension DIM.
Let MASK have dimension
(l1:u1,
l2:u2,
...,
ln:un).
Let DIM have the value i.
The result of FIRSTLOC(MASK,DIM) or LASTLOC(MASK,DIM) is obtained by
applying FIRSTLOC or LASTLOC to each of the following sections and
storing the result in the corresponding element of the result array:
(l1, l2, ... , li-1 , : ,
li+1, ... , ln-1, ln)
(l1+1, l2, ... , li-1 , : ,
li+1, ... , ln-1, ln)
(l1+2, l2, ... , li-1 , : ,
li+1, ... , ln-1, ln)
.
.
.
(u1, u2, ... , ui-1 , : ,
ui+1, ... , un-1, un-1)
(u1, u2, ... , ui-1 , : ,
ui+1, ... , un-1, un)
If MASK is
F F T F
F T T F
F T F T
F F F F
where "T" represents .TRUE. and "F" represents .FALSE.
Case (i): FIRSTLOC(MASK) is
F F F F
F T F F
F F F F
F F F F
(The only T is the first T in array element order)
LASTLOC(MASK) is
F F F F
F F F F
F F F T
F F F F
(The only T is the last T in array element order)
Case (ii):
FIRSTLOC(MASK,DIM=1) is the "top edge"
F F T F
F T F F
F F F T
F F F F
(The only T's are the first T in each column)
LASTLOC(MASK,DIM=2) is the "right edge"
F F T F
F F T F
F F F T
F F F F
(The only T's are the last T in each row)
Implementation of these features will not affect existing code.
[ Sections F.2.4.5 and F.2.4.6 of S8.104 Appendix F (aka
X3J3/119-LJM-1)
]
X3J3
May 93, meeting 125:
Status changed to Archival (UC).
Mar 93:
Sections F.2.4.5 and F.2.4.6 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).
-----------------------------------------------------------------------
010
Nesting of Internal Procedures
INTERNAL PROCEDURES, NESTING
Registered
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
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
1
Grandfather requirement from old Appendix F
If a dummy argument is a dummy procedure, the associated actual
argument must be the name of an external, internal, dummy, or
intrinsic procedure.
[To be supplied if the STATUS is changed from "Registered" to "X3J3
consideration in progress". Requirement "grandfathered".]
If the internal procedure is supplied as an actual argument from an
instance of the subprogram or procedure having access to the
entities of that instance, the instance of that internal procedure
created by invoking the associated dummy procedure also has access
by use or host association to the entities of that instance of the
host subprogram.
All other entities, including saved data objects, are common to all
instances of the subprogram. For example, the value of a saved data
object appearing in one instance may have been defined in a previous
instance or by a DATA attribute or a DATA statement.
This addition will not affect existing code.
[ Section F.3.2 of S8.104 Appendix F (aka X3J3/119-LJM-1)
]
X3J3
May 93, meeting 125:
Status changed to Archival (19-5).
Mar 93:
Section F.3.2 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).
-----------------------------------------------------------------------
012
Condition Handling
CONDITION, ENABLE, SIGNAL, HANDLER, EXCEPTION
X3J3 approved; ready for WG5 (2000 revision)
1
Grandfather requirement from old Appendix F
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
| 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:
| 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 consideration in progress
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
| Jul 93, WG5 meeting:
| Recommended for 1995 revision (resolution B9, item B4.2)
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
X3J3 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
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 WG5 (1995 revision)
2
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
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
X3J3 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
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
X3J3 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
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:
| 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:
| 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
Registered
1
Provide a suggested DIRECTIVE syntax for Fortran programmers.
Users of Fortran would benefit from more commonality of directives,
and better mechanisms for identifying directives which are not safe
to ignore.
[ X3J3/93-171
][ Minutes from various Fortran 90 implementation symposia
]
Rich Bleikamp for X3J3/parallel subgroup
bleikamp@convex.com, 214-306-6393
May 93, meeting 125:
Proposal X3J3/93-171 presented by Rich Bleikamp.
-----------------------------------------------------------------------
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
| Jul 93, WG5 meeting:
| Removal of conflicts recommended 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
Registered
1
Permit Interline Optimizations.
Consider the case mentioned in X3J3/93-132:
10 SUM = A+B
20 D = SUM+C
It is forbidden for a Standard Conforming Processor to transform
this into
D = A+B+C
whenever it makes a computational difference. While this sometimes
makes careful numerical analysts happy, it makes many other people
unhappy because on some hardware platforms it runs slower.
New block statements, REORDER, NOREORDER, END would permit
users to inform their processor of their preference.
A standard conforming processor would default to NOREORDER (for
conformance with the existing standard). However, it is believed
that many processors will provide a compiler option to reverse the
default, therefore the need for NOREORDER.
Machines with special MULADD (e.g., power PC) or special wide
internal registers (e.g. x86, 68K, Convex) may perform significantly
better when interline optimizations are permitted. However, blanket
permission to reorder makes life difficult for numerical analysts.
This would allow users the freedom to obtain whatever behavior they
desire.
This is preferable to compiler options, because it is possible to
"guard" only key computations rather than entire program units.
There will be no impact on existing programs.
Existing processors will have to augment their "grammars" trivially.
Optimizers may optionally be modified to take advantage of these new
opportunities for optimization.
[ X3J3/93-132
]
Keith H. Bierman, Keith.Bierman@eng.sun.com
May 93:
Proposal prepared by Keith Bierman
-----------------------------------------------------------------------
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
Efficient Varying Length Character Type
VARYING LENGTH, CHARACTER, MAXIMUM LENGTH
Registered
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
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
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
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
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.
-----------------------------------------------------------------------