###################################################################### # # # X3J3/94-004r0 # # Journal Of Requirements # # (Full Version) # # # # Feb 1994 # # # ###################################################################### INTRODUCTION | This document is the Fortran Journal of Requirements (or JOR), | internal standing document 004 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. | There are both "full" and "subset" versions of the JOR. The latter | omits all but the first few fields for pFRs which are, for one reason | or another, no longer under active consideration. The header at the | top of this document should indicate whether it is the full or subset | version, and should include its X3J3 document number which should help | identify it on the ftp server. 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 or simply WG5) has final authority over all future | Fortran standards. US positions on WG5 issues are determined by the | US Technical Advisory Group, or TAG, which consists of US members of | X3J3. 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 a vote of the 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 US TAG or Failed WG5 approval (Fail) | Failed to gain approval by a vote of the US TAG after forwarding | from X3J3; or rejected by WG5 after forwarding from the US TAG. This status is equivalent to "Registered". Archival (Arch) Withdrawn from active consideration by X3J3; requires a | two-thirds vote of the committee. Fields following are | omitted in the subset version of the JOR. LIST OF PROPOSED FORTRAN REQUIREMENTS 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 Reg Language Management 015 US 1995 Conditional Compilation | 016 Reg 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 US 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 | 049 Reg Generalize Constructors Into Generic Procedures ###################################################################### 001 Bit Data Type, Non-string <KEYWORDS> BIT, INTRINSIC, DATA TYPE <STATUS> Archival <TARGET> <VERSION> 1 <NOTE> Grandfather requirement from old Appendix F <REQUIREMENT> 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. <JUSTIFICATION> [To be supplied; requirement "grandfathered".] <SUGGESTED IMPLEMENTATION> 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]. <H1> Bit Constant Rule R306 for literal constants must be extended to include a bit constant. <RULE> literal-constant <IS> int-literal-constant <OR> real-literal-constant <OR> complex-literal-constant <OR> logical-literal-constant <OR> char-literal-constant <OR> boz-literal-constant <OR> bit-literal-constant </RULE> <H1> Bit Operators Rule R310 for intrinsic operators must be extended to include bit operators. <RULE> intrinsic-operator <IS> power-op <OR> mult-op <OR> add-op <OR> bnot-op <OR> band-op <OR> bor-op <OR> concat-op <OR> rel-op <OR> not-op <OR> and-op <OR> or-op <OR> equiv-op <RULE> bnot-op <IS> <SL>.BNOT.</> <RULE> band-op <IS> <SL>.BAND.</> <RULE> bor-op <IS> <SL>.BOR.</> <OR> <SL>.BXOR.</> </RULE> <H1> Bit Type The <GLOSS>bit type</> has two values which represent the bit values zero and one. Each of these values has two literal representations. <RULE> bit-literal-constant <IS> <SL>B'0'</> <OR> <SL>B'I'</> <OR> <SL>B"0"</> <OR> <SL>B"1"</> </RULE> 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. <H1> 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. <RULE> type-spec <IS> <SL>INTEGER</> [ kind-selector ] <OR> <SL>REAL</> [ kind-selector ] <OR> <SL>DOUBLE PRECISION</> <OR> <SL>COMPLEX</> [ kind-selector ] <OR> <SL>CHARACTER</> [ char-selector ] <OR> <SL>LOGICAL</> [ kind-selector ] <OR> <SL>BIT</> <OR> <SL>TYPE</> ( type-name ) </RULE> The BIT type specifier specifies that all objects whose names are declared in this statement are of intrinsic type bit. An <SC>equivalence-object</> must not be the name of an object of bit type. A <SC>common-block-object</> must not be the name of an object of bit type. The variables or arrays whose names are included in the <SC>data-i- do-object-list</> must not be of type bit. <H1> Bit Expressions <H2> 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 <SC>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 <SC>defined-unary- op</> and <SC>defined-binary-op</>. The semantics are specified in 7.1.3 and 7.1.7. <H2> Primary <RULE LABEL=R701> primary <IS> constant <OR> variable <OR> array-constructor <OR> structure-constructor <OR> function-reference <OR> ( expr ) </RULE> Examples of a <SC>primary</> are: <TABLE> Example Syntactic Class ======================================================= 1.0 <SC>constant</> A <SC>variable</> [1.0,2.0] <SC>array-constructor</> PERSON('Jones', 12) <SC>structure-constructor</> F(X,Y) <SC>function-reference</> (S+T) (<SC>expr</>) </TABLE> <H2> 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: <RULE LABEL=R703> level-1-expr <IS> [ defined-unary-op ] primary <RULE LABEL=R704> defined-unary-op <IS> <SL>.</> letter [ letter ]... <SL>.</> </RULE> Simple examples of a <SC>level-1-expr</> are: <TABLE> Example Syntactic Class ========================================== A primary .INVERSE. B level-1-expr </TABLE> A more complicated example of a level-1 expression is: <XMP> .INVERSE. (A + B) </XMP> <H2> Level-2 Expressions Level-2 expressions are level-1 expressions optionally involving the numeric operators <SC>power-op</>, <SC>mult-op</>, and <SC>add- op</>. <RULE LABEL=R705> mult-operand <IS> level-1-expr [ power-op mult-operand ] <RULE LABEL=R706> add-operand <IS> [ add-operand mult-op ] mult-operand <RULE LABEL=R707> level-2-expr <IS> [ add-op ] add-operand <OR> level-2-expr add-op add-operand <RULE LABEL=R708> power-op <IS> ** <RULE LABEL=R709> mult-op <IS> * <OR> / <RULE LABEL=R710> add-op <IS> + <OR> - </RULE> Simple examples of a level-2 expression are: <TABLE> Example Syntactic Class ========================================== A level-1-expr B ** C mult-operand D * E add-operand F - I level-2-expr +1 level-2-expr </TABLE> A more complicated example of a level-2 expression is: <XMP> - A + D * E + B ** C </XMP> <H2> Level-3 Expressions Level-3 expressions are level-2 expressions optionally involving the bit operators <SC>bnot-op</>, <SC>band-op</>, and <SC>bor- op</>. <RULE> band-operand <IS> [ bnot-op ] level-2-expr <RULE> bor-operand <IS> [ bor-operand band-op ] band-operand <RULE> level-3-expr <IS> [ level-3-expr bor-op ] bor-operand <RULE> bnot-op <IS> <SL>.BNOT.</> <RULE> band-op <IS> <SL>.BAND.</> <RULE> bor-op <IS> <SL>.BOR.</> <OR> <SL>.BXOR.</> </RULE> Simple examples of a level-3 expression are: <TABLE> 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 </TABLE> A more complicated example of a level-3 expression is: <XMP> A .BXOR. B .BAND. .BNOT. C </XMP> <H2> Level-4 Expressions Level-4 expressions are level-3 expressions optionally involving the character operator <SC>concat-op</>. <RULE> level-4-expr <IS> [ level-4-expr concat-op ] level-3-expr <RULE LABEL=R712> concat-op <IS> // </RULE> Simple examples of a level-4 expression are: <TABLE> Example Syntactic Class ========================================== A level-3-expr B // C level-4-expr </TABLE> A more complicated example of a level-4 expression is: <XMP> X // Y // 'ABCD' </XMP> <H2> Level-5 Expressions Level-5 expressions are level-4 expressions optionally involving the relational operators <SC>rel-op</>. <RULE> level-5-expr <IS> [ level-4-expr rel-op ] level-4- expr <RULE LABEL=R714> rel-op <IS> <SL>.EQ.</> <OR> <SL>.NE.</> <OR> <SL>.LT.</> <OR> <SL>.LE.</> <OR> <SL>.GT.</> <OR> <SL>.GE.</> <OR> == <OR> /= <OR> < <OR> <= <OR> > <OR> >= </RULE> Simple examples of a level-5 expression are: <TABLE> Example Syntactic Class ========================================== A level-4-expr B .EQ. C level-5-expr D < E level-5-expr </TABLE> A more complicated example of a level-5 expression is: <XMP> (A + B) .NE. C </XMP> <H2> Level-6 Expressions Level-6 expressions are level-5 expressions optionally involving the logical operators <SC>not-op</>, <SC>and-op</>, <SC>or-op</>, and <SC>equiv-op</>. <RULE> and-operand <IS> [ not-op ] level-5-expr <RULE LABEL=R716> or-operand <IS> [ or-operand and-op ] and-operand <RULE LABEL=R717> equiv-operand <IS> [ equiv-operand or-op ] or-operand <RULE> level-6-expr <IS> [ level-6-expr equiv-op ] equiv-operand <RULE LABEL=R719> not-op <IS> <SL>.NOT.</> <RULE LABEL=R720> and-op <IS> <SL>.AND.</> <RULE LABEL=R721> or-op <IS> <SL>.OR.</> <RULE LABEL=R722> equiv-op <IS> <SL>.EQV.</>9 <OR> <SL>.NEQV.</> </RULE> Simple examples of a level-6 expression are: <TABLE> 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 </TABLE> A more complicated example of a level-6 expression is: <XMP> A .AND. B .EQV. .NOT. C </XMP> A <GLOSS>bit intrinsic operation</>, <GLOSS>character intrinsic operation</>, <GLOSS>relational intrinsic operation</>, and <GLOSS>logical intrinsic operation</> are similarly defined in terms of a <SC>bit intrinsic operator</> (.BAND., .BOR., .BXOR., and .BNOT.), <SC>character intrinsic operator</> (//), <SC>relational intrinsic operator</> (.EQ., .NE., .GT., .GE., .LT., .LE., ==, <>, >, >=, <, and <=), and <SC>logical intrinsic operator</> (.AND., .OR., .NOT., .EQV., and .NEQV.), respectively. A <GLOSS>bit relational intrinsic operation</> is a relational intrinsic operation where the operands are of type bit and the operator is .EQ., .NE., ==, or <>. <TABLE> <CAPTION> Type of Operands and Result for the Intrinsic Operation [<SC>x</>_1] <SC>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.) </CAPTION> 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. </TABLE> <H2> 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 <XMP> B1 .BOR. B2 .BOR. B3 </XMP> as <XMP> B1 .BOR. (B2 .BOR. B3) </XMP> Two expressions of type bit are bit-wise equivalent if their values are equal for all possible values of their primaries. <H2> 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. <TABLE> <CAPTION> Interpretation of the Bit Intrinsic Operators. </CAPTION> 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 </TABLE> The values of bit intrinsic operations are shown in Table F.3. <TABLE> <CAPTION> The Values of Operations Involving Bit Intrinsic Operators </CAPTION> 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' </TABLE> Derived-type operands may contain bit components. <H2> 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 <TABLEREF ID=PRECEDENCE_TABLE>. <TABLE> <CAPTION ID=PRECEDENCE_TABLE> Categories of Operations and Relative Precedences. </CAPTION> Category of Operation Operators Precedence =========================================================== Extension <SC>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 <SC>defined-binary-op</> Lowest </TABLE> The precedence of a defined operation is that of its operator, whether it is an overloaded intrinsic operator or an extension operator. <H1> 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. <H2> General Form of the Masked Array Assignment A <GLOSS>masked array assignment is either a WHERE statement or WHERE construct. <RULE LABEL=R738> where-stmt <IS> <SL>WHERE</> ( mask-expr ) assignment-stmt <RULE LABEL=R739> where-construct <IS> where-construct-stmt <NL> [ assignment-stmt ]... <NL> [ elsewhere-stmt <NL> [ assignment-stmt ]... ]<NL> end-where-stmt <RULE LABEL=R740> where-construct-stmt <IS> <SL>WHERE</> ( mask-expr ) <RULE> mask-expr <IS> logical-expr <OR> bit-expr <RULE LABEL=R742> elsewhere-stmt <IS> <SL>ELSEWHERE</> <RULE LABEL=R743> end-where-stmt <IS> <SL>END WHERE</> <CONSTRAINT> The shape of the <SC>mask-expr</> and the variable being defined in each <SC>assignment-stmt</> must be the same. </CONSTRAINT> Examples of a masked array assignment are: <XMP> WHERE (BIT_ARRAY_TEMP) TEMP = TEMP - REDUCE_TEMP WHERE (BIT_ARRAY_PRESSURE) PRESSURE = PRESSURE + INC_PRESSURE TEMP = TEMP - 5.0 END WHERE </XMP> <H2> Interpretation of Masked Array Assignments The execution of a masked array assignment causes the expression <SC>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 <SC>assignment-stmt</> is executed in a masked array assignment, the <SC>expr</> in the <SC>where-stmt</> or each <SC>expr</> in the array assignment statements, immediately following the WHERE keyword, is evaluated for all elements where <SC>mask-expr</> is true (or for all elements where <SC>mask- expr</> is false in the array assignment statements following ELSEWHERE), and the result is assigned to the corresponding elements of <SC>variable</>. For each false value of <SC>mask- expr</> (or true value for the array assignment statements after ELSEWHERE) the value of the corresponding element of <SC>variable</> in each array assignment statement immediately following the WHERE keyword is not affected, and it is as if the expression <SC>expr</> were not evaluated. If a <SC>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 <SC>expr</>, it is evaluated without any masked control by the <SC>mask-expr</>; that is, all of its argument expressions are fully evaluated and the function is fully evaluated. Elements corresponding to true values in <SC>mask-expr</> (false in the <SC>expr</> after ELSEWHERE) are selected for use in evaluating each <SC>expr</>. In a masked array assignment, only a WHERE statement may be a branch target. Changes to entities in <SC>mask-expr</> do not affect the execution of statements in the masked array assignment. Execution of an END WHERE has no effect. <H1> Bit Expressions in Control Constructs <H2> 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. <H2> 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. <H2> CASE Construct A case expression may be a scalar bit expression. Rule R812 must be extended. <RULE> case-expr <IS> scalar-int-expr <OR> scalar-char-expr <OR> scalar-logical-expr <OR> scalar-bit-expr </RULE> A corresponding case value in a case selector may be a scalar bit constant expression. Rule R815 must be extended. <RULE LABEL=R814> case-value-range <IS> case-value <OR> case-value : <OR> : case-value <OR> case-value : case-value <RULE> case-value <IS> scalar-int-constant-expr <OR> scalar-char-constant-expr <OR> scalar-logical-constant-expr <OR> scalar-bit-constant-expr </RULE> If the case value range is of the form <SC>low</>: or :<SC>high</>, the data type must not be bit. <H1> Bit Input/Output Editing <H2> Bit Edit Descriptor There is a bit edit descriptor: B. Rule R1005 must be extended. <RULE LABEL=1005> data-edit-desc <IS> <SL>I</> w [ . m ] <OR> <SL>F</> w . d <OR> <SL>E</> w . d [ <SL>E</> e ] <OR> <SL>EN</> w . d [ <SL>E</> e ] <OR> <SL>G</> w . d [ <SL>E</> e ] <OR> <SL>B</> w <OR> <SL>L</> w <OR> <SL>A</> [ w ] <OR> <SL>D</> w . d </RULE> <H2> B Editing The B<SC>w</> edit descriptor indicates that the field occupies <SC>w</> positions. The specified input/output list item must be of type bit. The input field consists of <SC>w</>- 1 blanks and either a 0 or a 1, in any order. The output field consists of <SC>w</>- 1 blanks followed by either a 0 or a 1. The specifiers BZ and BN have no effect on bit editing. <H2> 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. <H1> 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. <TABLE> 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 </TABLE> <FUNCTION> BITL (L) <DESCRIPTION> Convert logical to bit type. <KIND> Elemental function. <ARGUMENT> L must be of type logical. <RESULT_TYPE> Bit. <RESULT_VALUE> The result has the value B'1' if L has the value .TRUE. and the value B'0' if L has the value .FALSE. <EXAMPLE> BITL (.TRUE.) has the value B'1'. <FUNCTION> BITLR (I, SIZE) <OPTIONAL_ARGUMENT> SIZE <DESCRIPTION> Convert an integer to a bit array, counting left to right. <KIND> Transformational function. <ARGUMENTS> 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). <RESULT_TYPE_AND_SHAPE> The result is a bit array of rank one with SIZE number of elements. <RESULT_VALUE> 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). <EXAMPLE> BITLR (5, 6) has the value [B'0', B'0', B'0', B'1', B'0', B'1']. <FUNCTION> BITRL (I, SIZE) <OPTIONAL_ARGUMENT> SIZE <DESCRIPTION> Convert an integer to a bit array, counting right to left. <KIND> Transformational function. <ARGUMENTS> 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). <RESULT_TYPE_AND_SHAPE> The result is a bit array of rank one with SIZE number of elements. <RESULT_VALUE> 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). <EXAMPLE> BITRL (5, 6) has the value [B'1', B'0', B'1', B'0', B'0', B'0']. <FUNCTION> IBITLR (B) <DESCRIPTION> Convert a bit array to an integer, counting left to right. <KIND> Transformational function. <ARGUMENT> B must be of type bit and rank one. Its size must satisfy the inequality ESIZE (B) <= MAXBITS (1). <RESULT_TYPE_AND_SHAPE> Scalar integer. <RESULT_VALUE> 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). <EXAMPLE> IBITLR ([B'0', B'1', B'0', B'1']) has the value 5. <FUNCTION> IBITRL (B) <DESCRIPTION> Convert a bit array to an integer, counting right to left. <KIND> Transformational function. <ARGUMENT> B must be of type bit and rank one. Its size must satisfy the inequality ESIZE (B) <= MAXBITS (1). <RESULT_TYPE_AND_SHAPE> Scalar integer. <RESULT_VALUE> 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). <EXAMPLE> IBITRL ([B'1', B'0', B'1', B'0']) has the value 5. <FUNCTION> LBIT (B) <DESCRIPTION> Convert bit to logical type. <KIND> Elemental function. <ARGUMENT> B must be of type bit. <RESULT_TYPE> Logical. <RESULT_VALUE> The result has the value .TRUE. if B has the value B'1' and the value .FALSE. if B has the value B'0'. <EXAMPLE> LBIT (B'1') has the value .TRUE. <FUNCTION> MAXBITS (I) <DESCRIPTION> Returns the maximum size of a bit array that can be converted to a value of type integer. <KIND> Inquiry function. <ARGUMENT> I must be of type integer. <RESULT_TYPE_AND_SHAPE> Integer scalar. <RESULT_VALUE> 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). </FUNCTION> <H1> 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. <H1> Bit Storage Sequence A bit data object has no storage sequence. </SUGGESTED IMPLEMENTATION> <REFLIST> <REF> X3J3/93-072 <REF> Section F.1.1 of S8.104 Appendix F (aka X3J3/119-LJM-1) </REFLIST> <SUBMITTED BY> X3J3 <HISTORY> <EVENT> May 93, meeting 125: Status changed to Archival (UC). <EVENT> 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). <EVENT> 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). <EVENT> Nov 87, Meeting 106: Conversion of S8.104 Appendix F to X3J3/S17, Journal Of Development, approved by X3J3 (18-12). </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 002 <TITLE> Variant Derived Type <KEYWORDS> DERIVED TYPE, VARIANT, TAG <STATUS> Registered <TARGET> <VERSION> 1 <NOTE> Grandfather requirement from old Appendix F <REQUIREMENT> 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. <JUSTIFICATION> [To be supplied if the STATUS is changed from "Registered" to "X3J3 consideration in progress". Requirement "grandfathered".] <SUGGESTED IMPLEMENTATION> 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. <COMPATIBILITY CONSIDERATIONS> No impact on existing code. <REFLIST> <REF> Section F.1.2 of S8.104 Appendix F (aka X3J3/119-LJM-1) </REFLIST> <SUBMITTED BY> X3J3 <HISTORY> <EVENT> Apr 93: Section F.1.2 of S8.104 Appendix F material reformatted by L. Moss. <EVENT> 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). <EVENT> Nov 87, Meeting 106: Conversion of S8.104 Appendix F to X3J3/S17, Journal Of Development, approved by X3J3 (18-12). </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 003 <TITLE> Array Components of Array Structures <KEYWORDS> ARRAYS, STRUCTURES, COMPONENTS, RANK, SHAPE <STATUS> Registered <TARGET> <VERSION> 1 <NOTE> Grandfather requirement from old Appendix F <REQUIREMENT> Treat array structures containing array components as higher-rank array objects; that is, remove the restriction against structure references containing more than one <SC>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. <JUSTIFICATION> [To be supplied if the STATUS is changed from "Registered" to "X3J3 consideration in progress". Requirement "grandfathered".] <REFLIST> <REF> Section F.2.1 of S8.104 Appendix F (aka X3J3/119-LJM-1) </REFLIST> <SUBMITTED BY> X3J3 <HISTORY> <EVENT> May 93, Meeting 125: Straw vote to change status to approved/archival/undecided: 8-4-12; no change. <EVENT> Apr 93: Section F.2.1 of S8.104 Appendix F material reformatted by L. Moss. <EVENT> 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). <EVENT> Nov 87, Meeting 106: Conversion of S8.104 Appendix F to X3J3/S17, Journal Of Development, approved by X3J3 (18-12). </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 004 <TITLE> FORALL <KEYWORDS> FORALL, STATEMENT, CONSTRUCT, ELEMENT ARRAY ASSIGNMENT <STATUS> US TAG approved; ready for WG5 <TARGET> 1995 revision <VERSION> 1 <REQUIREMENT> 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 <SC>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. <JUSTIFICATION> | A FORALL statement or construct would complement the array | assignments and WHERE constructs and statements in Fortran 90. It | permits a more general class of array sections to be manipulated, | and it is often easier to understand since the operation is | expressed in terms of individual array elements in a syntax | suggestive of a corresponding mathematical notation. <SUGGESTED IMPLEMENTATION> The FORALL construct of HPF. <COMPATIBILITY CONSIDERATIONS> 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. <REFLIST> | <REF> X3J3/94-096 FORALL proposal | <REF> X3J3/94-098 Pure procedures | <REF> X3J3/94-097 Rationale for FORALL and PURE | <REF> Item 13a of WG5 Requirements repository (N904). <REF> HPF <REF> Section F.2.3 of S8.104 Appendix F (aka X3J3/119-LJM-1) </REFLIST> <SUBMITTED BY> X3J3 <HISTORY> | <EVENT> Feb 94: | Justification drafted by Len Moss. | <EVENT> Feb 94, meeting 128: | Draft 009 specifications for FORALL and for PURE procedures, 94-096 | and 94-098, respectively, and a combined rationale document, 94-097, | approved by unanimous consent. <EVENT> Nov 93: Without objections from US TAG following Nov 93 X3J3 meeting, automatically promoted to "US TAG approved; ready for WG5". <EVENT> Jul 93, WG5 meeting: WG5 tentatively approved for 1995 revision (resolution B9, items A2 and A3) <EVENT> May 93, meeting 125: Status changed to approved/1995 (UC). <EVENT> Apr 93: Section F.2.3 of S8.104 Appendix F material reformatted by L. Moss. <EVENT> 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). <EVENT> 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). <EVENT> Nov 87, Meeting 106: Conversion of S8.104 Appendix F to X3J3/S17, Journal Of Development, approved by X3J3 (18-12). </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 005 <TITLE> DIAGONAL Function <KEYWORDS> DIAGONAL, FUNCTION, ARRAY, FILL, MATRIX, VECTOR <STATUS> Archival <TARGET> <VERSION> 1 <NOTE> Grandfather requirement from old Appendix F <REQUIREMENT> 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. <JUSTIFICATION> [To be supplied if the STATUS is changed from "Registered" to "X3J3 consideration in progress". Requirement "grandfathered".] <REFLIST> <REF> Section F.2.4.1 of S8.104 Appendix F (aka X3J3/119-LJM-1) </REFLIST> <SUBMITTED BY> X3J3 <HISTORY> <EVENT> May 93, meeting 125: Status changed to Archival (UC). <EVENT> Apr 93: Section F.2.4.1 of S8.104 Appendix F material reformatted by L. Moss. <EVENT> 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). <EVENT> Nov 87, Meeting 106: Conversion of S8.104 Appendix F to X3J3/S17, Journal Of Development, approved by X3J3 (18-12). </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 006 <TITLE> PROJECT Function <KEYWORDS> PROJECT, FUNCTION, ARRAY, MASK, FIELD, REDUCE RANK <STATUS> Archival <TARGET> <VERSION> 1 <NOTE> Grandfather requirement from old Appendix F <REQUIREMENT> 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. <JUSTIFICATION> [To be supplied if the STATUS is changed from "Registered" to "X3J3 consideration in progress". Requirement "grandfathered".] <REFLIST> <REF> Section F.2.4.2 of S8.104 Appendix F (aka X3J3/119-LJM-1) </REFLIST> <SUBMITTED BY> X3J3 <HISTORY> <EVENT> May 93, meeting 125: Status changed to Archival (23-1). <EVENT> Apr 93: Section F.2.4.2 of S8.104 Appendix F material reformatted by L. Moss. <EVENT> 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). <EVENT> Nov 87, Meeting 106: Conversion of S8.104 Appendix F to X3J3/S17, Journal Of Development, approved by X3J3 (18-12). </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 007 <TITLE> REPLICATE Function <KEYWORDS> REPLICATE, FUNCTION, ARRAY <STATUS> Archival <TARGET> <VERSION> 1 <NOTE> Grandfather requirement from old Appendix F <REQUIREMENT> 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. <JUSTIFICATION> [To be supplied if the STATUS is changed from "Registered" to "X3J3 consideration in progress". Requirement "grandfathered".] <REFLIST> <REF> Section F.2.4.3 of S8.104 Appendix F (aka X3J3/119-LJM-1) </REFLIST> <SUBMITTED BY> X3J3 <HISTORY> <EVENT> May 93, meeting 125: Status changed to Archival (UC). <EVENT> Apr 93: Section F.2.4.3 of S8.104 Appendix F material reformatted by L. Moss. <EVENT> 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). <EVENT> Nov 87, Meeting 106: Conversion of S8.104 Appendix F to X3J3/S17, Journal Of Development, approved by X3J3 (18-12). </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 008 <TITLE> RANK Intrinsic Function <KEYWORDS> RANK, INTRINSIC, INQUIRY FUNCTION <STATUS> Archival <TARGET> <VERSION> 1 <NOTE> Grandfather requirement from old Appendix F <REQUIREMENT> 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. <JUSTIFICATION> [To be supplied if the STATUS is changed from "Registered" to "X3J3 consideration in progress". Requirement "grandfathered".] <COMPATIBILITY CONSIDERATIONS> No impact on existing code. <REFLIST> <REF> Section F.2.4.4 of S8.104 Appendix F (aka X3J3/119-LJM-1) </REFLIST> <SUBMITTED BY> X3J3 <HISTORY> <EVENT> May 93, meeting 125: Status changed to Archival (23-1). <EVENT> Mar 93: Section F.2.4.4 of S8.104 Appendix F material reformatted by D. Mattoon. <EVENT> 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). <EVENT> 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). <EVENT> Nov 87, Meeting 106: Conversion of S8.104 Appendix F to X3J3/S17, Journal Of Development, approved by X3J3 (18-12). </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 009 <TITLE> FIRSTLOC and LASTLOC intrinsics <KEYWORDS> FIRSTLOC, LASTLOC, INTRINSIC <STATUS> Archival <TARGET> <VERSION> 1 <NOTE> Grandfather requirement from old Appendix F <REQUIREMENT> 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. <JUSTIFICATION> [To be supplied if the STATUS is changed from "Registered" to "X3J3 consideration in progress". Requirement "grandfathered".] <SUGGESTED IMPLEMENTATION> 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 (l<sub>1</sub>:u<sub>1</sub>, l<sub>2</sub>:u<sub>2</sub>, ..., l<sub>n</sub>:u<sub>n</sub>). 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: <TABLE> (l<sub>1</sub>, l<sub>2</sub>, ... , l<sub>i-1</sub> , : , l<sub>i+1</sub>, ... , l</sub>n-1</sub>, l</sub>n</sub>) (l<sub>1</sub>+1, l<sub>2</sub>, ... , l<sub>i-1</sub> , : , l<sub>i+1</sub>, ... , l</sub>n-1</sub>, l</sub>n</sub>) (l<sub>1</sub>+2, l<sub>2</sub>, ... , l<sub>i-1</sub> , : , l<sub>i+1</sub>, ... , l</sub>n-1</sub>, l</sub>n</sub>) . . . (u<sub>1</sub>, u<sub>2</sub>, ... , u<sub>i-1</sub> , : , u<sub>i+1</sub>, ... , u</sub>n-1</sub>, u</sub>n</sub>-1) (u<sub>1</sub>, u<sub>2</sub>, ... , u<sub>i-1</sub> , : , u<sub>i+1</sub>, ... , u</sub>n-1</sub>, u</sub>n</sub>) </TABLE> <EXAMPLES> If MASK is <MATRIX> <ROW> F F T F <ROW> F T T F <ROW> F T F T <ROW> F F F F </MATRIX> where "T" represents .TRUE. and "F" represents .FALSE. Case (i): FIRSTLOC(MASK) is <MATRIX> <ROW> F F F F <ROW> F T F F <ROW> F F F F <ROW> F F F F </MATRIX> (The only T is the first T in array element order) LASTLOC(MASK) is <MATRIX> <ROW> F F F F <ROW> F F F F <ROW> F F F T <ROW> F F F F </MATRIX> (The only T is the last T in array element order) Case (ii): FIRSTLOC(MASK,DIM=1) is the "top edge" <MATRIX> <ROW> F F T F <ROW> F T F F <ROW> F F F T <ROW> F F F F </MATRIX> (The only T's are the first T in each column) LASTLOC(MASK,DIM=2) is the "right edge" <MATRIX> <ROW> F F T F <ROW> F F T F <ROW> F F F T <ROW> F F F F </MATRIX> (The only T's are the last T in each row) </EXAMPLES> </SUGGESTED IMPLEMENTATION> <COMPATIBILITY CONSIDERATIONS> Implementation of these features will not affect existing code. <REFLIST> <REF> Sections F.2.4.5 and F.2.4.6 of S8.104 Appendix F (aka X3J3/119-LJM-1) </REFLIST> <SUBMITTED BY> X3J3 <HISTORY> <EVENT> May 93, meeting 125: Status changed to Archival (UC). <EVENT> Mar 93: Sections F.2.4.5 and F.2.4.6 of S8.104 Appendix F material reformatted by D. Mattoon. <EVENT> 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). <EVENT> Nov 87, Meeting 106: Conversion of S8.104 Appendix F to X3J3/S17, Journal Of Development, approved by X3J3 (18-12). </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 010 <TITLE> Nesting of Internal Procedures <KEYWORDS> INTERNAL PROCEDURES, NESTING <STATUS> US TAG approved; ready for WG5 <TARGET> <VERSION> 1 <REQUIREMENT> An internal procedure may host other internal procedures. <JUSTIFICATION> | Internal procedures have a broad spectrum of uses. At one end, as | generalizations of statement functions, simple internal procedures | are good candidates for in-lining by an aggressive compiler; at the | other, because of their limited scope, they provide a convenient way | to divide the internals of a large, complex library routine into | manageable pieces. Unfortunately, because of the restriction | against nesting an internal procedure in the latter category cannot | itself take advantage of one in the former. Now that a number of | implementers have experience with Fortran 90, the restriction | against nesting internal procedures should be reviewed and, if | possible, relaxed. <COMPATIBILITY CONSIDERATIONS> This will not directly affect existing code. <REFLIST> | <REF> Item 33 of WG5 Requirements repository (N904). <REF> Section F.3.1 of S8.104 Appendix F (aka X3J3/119-LJM-1) </REFLIST> <SUBMITTED BY> X3J3 <HISTORY> | <EVENT> Feb 94: | Justification drafted by Len Moss. <EVENT> Nov 93: Without objections from US TAG following Nov 93 X3J3 meeting, automatically promoted to "US TAG approved; ready for WG5". <EVENT> 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. <EVENT> May 93, meeting 125: Motion to approve for 2000 failed two-thirds vote (15-1); unchanged. <EVENT> Mar 93: Section F.3.1 of S8.104 Appendix F material reformatted by D. Mattoon. <EVENT> 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). <EVENT> Nov 87, Meeting 106: Conversion of S8.104 Appendix F to X3J3/S17, Journal Of Development, approved by X3J3 (18-12). </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 011 <TITLE> Internal Procedure Names as Actual Arguments <KEYWORDS> INTERNAL PROCEDURES, ARGUMENTS <STATUS> Archival <TARGET> <VERSION> 1 <NOTE> Grandfather requirement from old Appendix F <REQUIREMENT> If a dummy argument is a dummy procedure, the associated actual argument must be the name of an external, internal, dummy, or intrinsic procedure. <JUSTIFICATION> [To be supplied if the STATUS is changed from "Registered" to "X3J3 consideration in progress". Requirement "grandfathered".] <IMPLEMENTATION CONSIDERATIONS> 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. </IMPLEMENTATION CONSIDERATIONS> <COMPATIBILITY CONSIDERATIONS> This addition will not affect existing code. <REFLIST> <REF> Section F.3.2 of S8.104 Appendix F (aka X3J3/119-LJM-1) </REFLIST> <SUBMITTED BY> X3J3 <HISTORY> <EVENT> May 93, meeting 125: Status changed to Archival (19-5). <EVENT> Mar 93: Section F.3.2 of S8.104 Appendix F material reformatted by D. Mattoon. <EVENT> 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). <EVENT> Nov 87, Meeting 106: Conversion of S8.104 Appendix F to X3J3/S17, Journal Of Development, approved by X3J3 (18-12). </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 012 <TITLE> Condition Handling <KEYWORDS> CONDITION, ENABLE, SIGNAL, HANDLER, EXCEPTION <STATUS> US TAG approved; ready for WG5 <TARGET> 2000 revision <VERSION> 1 <NOTE> Related to pFR 28 (Binding to IEEE 754) and pFR 32 (POSIX binding to Fortran 90) </NOTE> <REQUIREMENT> 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: <LIST> <ITEM> 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. <ITEM> User-defined conditions, declared with a new specification statement and signalled explicitly by a new executable statement. <ITEM> Dummy condition arguments. <ITEM> 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. <ITEM> 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. <ITEM> 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. <ITEM> Default handlers to handle any condition. <ITEM> Appropriate inquiry functions to determine whether a condition has been enabled and whether a handler has been established for it. </LIST> <JUSTIFICATION> | A structured approach to handling exceptional conditions would | improve both the maintainability and robustness of Fortran programs. | Much of the error handling code which clutters up the expression of | the underlying algorithm in current programs could instead be moved | to a separate handler. Such handlers would, in turn, encourage | programmers to write, and provide facilities to support, more | complete code for dealing with exceptional conditions. A | block-structured approach would preserve, for both the programmer | and the compiler, a clear connection between the code expressing an | algorithm and the associated exception handling code. <SUGGESTED IMPLEMENTATION> See section of S8.104 Appendix F. <REFLIST> | <REF> Item 5c of WG5 Requirements repository (N904). <REF> Section F.4.1 of S8.104 Appendix F (aka X3J3/119-LJM-1) </REFLIST> <SUBMITTED BY> X3J3 <HISTORY> | <EVENT> Feb 94: | Justification drafted by Len Moss. <EVENT> Nov 93: Without objections from US TAG following Nov 93 X3J3 meeting, automatically promoted to "US TAG approved; ready for WG5". <EVENT> 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). <EVENT> Jul 93, WG5 meeting: Investigation for 1995 revision requested (B9 Resolution, item C5) <EVENT> May 93, meeting 125: Status changed to approved/2000 (20-2). <EVENT> Apr 93: Section F.4.1 of S8.104 Appendix F material reformatted by L. Moss. <EVENT> 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). <EVENT> Nov 87, Meeting 106: Conversion of S8.104 Appendix F to X3J3/S17, Journal Of Development, approved by X3J3 (18-12). </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 013 <TITLE> Pointer Initialization <KEYWORDS> POINTER, INITIALIZATION, DISASSOCIATED, UNDEFINED <STATUS> Registered <TARGET> <VERSION> 1 <REQUIREMENT> Change the initial status of pointers from undefined to disassociated. <JUSTIFICATION> 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. <COMPATIBILITY CONSIDERATIONS> 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. <REFLIST> <REF> Item 1 of WG5 Requirements repository (N904). </REFLIST> <SUBMITTED BY> X3J3/JOR subgroup for DIN Fortran Working Group <HISTORY> <EVENT> Jul 93, WG5 meeting: WG5 recommended for 1995 revision (resolution B9, item B1) <EVENT> May 93, meeting 1254: Straw vote to change status to approved/archival/undecided: 7-8-10; no change. <EVENT> Feb 93, meeting 124: Vote to change the status to "X3J3 consideration in progress" fails (8-9). <EVENT> Feb 93, meeting 124: Registered by X3J3/JOR subgroup on behalf of DIN Fortran Working Group. <EVENT> Jul 92, WG5 Meeting: Presented to WG5 by Wolfgang Walter of DIN Fortran Working Group. </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 014 <TITLE> Language Management <KEYWORDS> EVOLUTION, OBSOLESCENT | <STATUS> Registered <TARGET> <VERSION> 1 <REQUIREMENT> A management plan for language evolution: move redundant features to the obsolescent list, design strategic functionality, and integrate the whole into a coherent language. <JUSTIFICATION> 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. <ESTIMATED IMPACT> 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. <REFLIST> <REF> Item 3 of WG5 Requirements repository (N904). <REF> ISO/IEC JTC1/SC22/WG5-N817. <REF> ISO/IEC JTC1/SC22/WG5-N781. </REFLIST> <SUBMITTED BY> X3J3/JOR subgroup for Aurelio Policini <HISTORY> | <EVENT> Feb 94, meeting 128: | Motion to archive failed two-thirds vote: 8-2. Motion to change | status back to "Registered" approved by unanimous consent. <EVENT> 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. <EVENT> Jul 93, WG5 meeting: WG5 recommended for 1995 revision (resolution B9, item B4.2) <EVENT> May 93, meeting 125: Straw vote to change status to approved/archival/undecided: 9-3-8; no change. <EVENT> Feb 93, meeting 124: Status changed to "X3J3 consideration in progress" (9-3). <EVENT> Feb 93, meeting 124: Registered by X3J3/JOR subgroup on behalf of Aurelio Policini. <EVENT> Jul 92, WG5 Meeting: Presented to WG5 by Aurelio Policini. </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 015 <TITLE> Conditional Compilation <KEYWORDS> CONDITIONAL COMPILATION, PREPROCESSOR <STATUS> US TAG approved; ready for WG5 <TARGET> 1995 revision <VERSION> 1 <REQUIREMENT> 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. <JUSTIFICATION> 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. <COMPATIBILITY CONSIDERATIONS> No impact on existing programs. Would add slightly to the burden of implementers. <REFLIST> <REF> Item 6 of WG5 Requirements repository (N904). <REF> ISO/IEC JTC1/SC22/WG5-N899. <REF> ISO/IEC JTC1/SC22/WG5-N539. </REFLIST> <SUBMITTED BY> X3J3/JOR subgroup for HPFF <HISTORY> <EVENT> Nov 93: Without objections from US TAG following Nov 93 X3J3 meeting, automatically promoted to "US TAG approved; ready for WG5". <EVENT> May 93, meeting 125: Status changed to approved/1995 (18-6). <EVENT> May 93, meeting 125: Motion to approve for 2000 failed two-thirds vote (15-1). <EVENT> Feb 93, meeting 124: Status changed to "X3J3 consideration in progress" (14-2). <EVENT> Feb 93, meeting 124: Registered by X3J3/JOR subgroup on behalf of HPFF. <EVENT> 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. </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 016 <TITLE> Command Line Arguments and Environmental Variables <KEYWORDS> COMMAND LINE | <STATUS> Registered <TARGET> 1995 revision <VERSION> 2 <NOTE> Related to pFR 32 (POSIX binding to Fortran 90) </NOTE> <REQUIREMENT> 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. <JUSTIFICATION> 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. <NOTE> 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. </NOTE> <IMPLEMENTATION CONSIDERATIONS> A summary of some vendor-specific implementations: <LIST> <ITEM> 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 <ITEM> Lahey Fortran: subroutine GETCL returns a string containing the command tail -- everything after the command and the blank separator. <ITEM> 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. <ITEM> 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. <ITEM> 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. </LIST> 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: <LIST> <ITEM> Parallel syntax or optional arguments to specify either environmental variables or the command line. <ITEM> 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. <ITEM> Ability to provide an error status including the fact that no command line can be provided or the specified environmental variable did not exist. <ITEM> Automatic parsing of the command line based on blank delimiters since many users want this feature without the bother of using the string intrinsics. <ITEM> Allowing for systems which can only return the command line tail vs systems which can return the full command line. </LIST> Open issues may include: <LIST> <ITEM> How to specify the length of the character variables for the command line arguments. <ITEM> How to specify the dimension of the array returning the command line arguments. </LIST> </IMPLEMENTATION CONSIDERATIONS> <COMPATIBILITY CONSIDERATIONS> This should not have an effect on existing code unless the intrinsic(s) clash with existing procedure names. <REFLIST> | <REF> Item 20 of WG5 Requirements repository (N904). <REF> Specified in a request from Boeing (X3J3/93-069). Expanded and generalized by David Mattoon. <REF> POSIX Fortran 77 binding. </REFLIST> <SUBMITTED BY> David Mattoon <HISTORY> | <EVENT> Feb 94, US TAG meeting and X3J3 meeting 128: | Returned to X3J3 by US TAG (16-1) for further consideration by the | new /OSCI subgroup as part of the POSIX requirement (pFR 032). | Subsequently, status reset to "Registered" by X3J3 (UC). <EVENT> 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). <EVENT> May 93, meeting 125: Status changed to approved/1995 (21-1). <EVENT> May 93, meeting 125: Motion to approve for 2000 failed (7-12). <EVENT> May 93, meeting 125: First proposal submitted by David Mattoon. </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 017 <TITLE> Bit Data Type, String <KEYWORDS> BIT, INTRINSIC, DATA TYPE, STRING <STATUS> US TAG approved; ready for WG5 <TARGET> 2000 revision <VERSION> 2 <REQUIREMENT> 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. <JUSTIFICATION> 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. <SUGGESTED IMPLEMENTATION> To be accomplished after WG5 authorization. <REFLIST> | <REF> Item 21 of WG5 Requirements repository (N904). <REF> X3J3/93-119 Lahey / BIT Data Type <REF> Section F.1.1 of S8.104 Appendix F (aka X3J3/119-LJM-1) </REFLIST> <SUBMITTED BY> Thomas M. Lahey Email: tlahe@lahey.com </SUBMITTED BY> <HISTORY> <EVENT> Nov 93: Without objections from US TAG following Nov 93 X3J3 meeting, automatically promoted to "US TAG approved; ready for WG5". <EVENT> May 93, meeting 125: Status changed to approved/2000 (22-2); original proposal revised by Tom Lahey. <EVENT> May 93, meeting 125: First proposal, X3J3/93-119, submitted by Thomas Lahey </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 018 <TITLE> Controlling Pointer Bounds <KEYWORDS> POINTERS, BOUNDS <STATUS> US TAG approved; ready for WG5 <TARGET> 2000 revision <VERSION> 1 <REQUIREMENT> Allow a user to specify the bounds of a pointer that is associated with a target by the pointer assignment statement. <JUSTIFICATION> 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. <COMPATIBILITY CONSIDERATIONS> This affects only the pointer facility. It will not invalidate any existing programs. <REFLIST> <REF> Item 2 of WG5 Requirements repository (N904). <REF> ISO/IEC JTC1/SC22/WG5-N780. </REFLIST> <SUBMITTED BY> Jeanne Martin Email: jtm@llnl.gov </SUBMITTED BY> <HISTORY> <EVENT> Nov 93: Without objections from US TAG following Nov 93 X3J3 meeting, automatically promoted to "US TAG approved; ready for WG5". <EVENT> May 93, meeting 125: Status changed to approved/2000 (17-4). <EVENT> May 93, meeting 125: Motion to approve for 1995 failed two-thirds vote (14-8). <EVENT> Apr 93: Registered. <EVENT> Jul 92, WG5 Meeting: Presented to WG5 by Jeanne Martin. </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 019 <TITLE> Variant Derived Type, Untagged <KEYWORDS> DERIVED TYPE, VARIANT <STATUS> Registered <TARGET> <VERSION> 1 <NOTE> Counter proposal to Item 2 of 93-004r <REQUIREMENT> 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. <JUSTIFICATION> 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. <SUGGESTED IMPLEMENTATION> 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. <COMPATIBILITY CONSIDERATIONS> No impact on existing code. <REFLIST> <REF> Item 2 of X3J3/93-004r <REF> X3J3/93-164 </REFLIST> <SUBMITTED BY> Greg Lindhorst, gregli@microsoft.com, 206-936-2169 <HISTORY> <EVENT> May 93, Meeting 125: Submitted as X3J3/93-164 </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 020 <TITLE> User Defined Elemental Functions <KEYWORDS> ELEMENTAL, FUNCTION <STATUS> Registered <TARGET> <VERSION> 1 <REQUIREMENT> The ability to define elemental functions. <JUSTIFICATION> 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. <SUGGESTED IMPLEMENTATION> 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 <COMPATIBILITY CONSIDERATIONS> No impact on existing code. <REFLIST> | <REF> X3J3/94-057 User-Defined Elemental Procedures | <REF> X3J3/94-052 User-Defined Elemental Procedures <REF> X3J3/93-163 </REFLIST> <SUBMITTED BY> Greg Lindhorst, gregli@microsoft.com, 206-936-2169 <HISTORY> | <EVENT> Feb 94, meeting 128: | Two alternatives proposals submitted by David Phillimore for | /parallel subgroup: 94-052, with ELEMENTAL as a procedure attribute; | and 94-057, with ELEMENTAL as a dummy argument attribute. Straw | vote on argument attribute vs. procedure attribute: 8-3-10. <EVENT> May 93, Meeting 125: Submitted as X3J3/93-163 </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 021 <TITLE> Obsolesce Fixed Source Form <KEYWORDS> SOURCE FORM, OBSOLESCENT <STATUS> Registered <TARGET> <VERSION> 1 <REQUIREMENT> Add fixed source form to the list of obsolescent features. <JUSTIFICATION> 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. <SUGGESTED IMPLEMENTATION> 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. <COMPATIBILITY CONSIDERATIONS> 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. <REFLIST> <REF> X3J3/93-161 </REFLIST> <SUBMITTED BY> Richard Maine, maine@altair.dfrf.nasa.gov <HISTORY> <EVENT> Jul 93, WG5 meeting: WG5 recommended for 1995 revision (resolution B9, item B4.2) <EVENT> May 93, meeting 125: Proposal X3J3/93-161 submitted by Richard Maine </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 022 <TITLE> Keep It Simple, Make It Fine <KEYWORDS> SIMPLIFY, RESTRICTIONS, SYNTAX RULES, CONSTRAINTS, OBSOLESCENT FEATURES <STATUS> Registered <TARGET> <VERSION> 1 <REQUIREMENT> 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 <specification-part>, 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 <char-selector>, <data-stmt>, and <common-stmt> that complicate the syntactical description of these features. <JUSTIFICATION> 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. <SUBMITTED BY> Jerry Wagener, jwagener@amoco.com <HISTORY> <EVENT> May 93: First proposal circulated via X3J3 email list by Jerry Wagener </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 023 <TITLE> User Defined Intrinsic Functions <KEYWORDS> INTRINSICS, CONSTANT EXPRESSIONS <STATUS> Registered <TARGET> <VERSION> 1 <REQUIREMENT> Provide a mechanism for user supplied functions to be used in contexts requiring a "constant expression", typically in specification statements. <JUSTIFICATION> 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. <COMPATIBILITY CONSIDERATIONS> None <REFLIST> <REF> X3J3/93-168 </REFLIST> <SUBMITTED BY> Rich Bleikamp for X3J3/parallel subgroup bleikamp@convex.com, 214-306-6393 </SUBMITTED BY> <HISTORY> <EVENT> Jul 93, WG5 meeting: Investigation for 1995 revision requested (B9 Resolution, item C3) <EVENT> May 93, meeting 125: Proposal X3J3/93-168 presented by Rich Bleikamp for X3J3/parallel subgroup </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 024 <TITLE> Nested WHERE Statements <KEYWORDS> WHERE STATEMENT, NESTING, PARALLELISM <STATUS> Registered <TARGET> <VERSION> 1 <REQUIREMENT> Adding support for nested WHERE statements may be desirable for expressing parallelism. <JUSTIFICATION> Facilitates extensions to Fortran environments by other standard bodies (e.g., HPFF). <COMPATIBILITY CONSIDERATIONS> None <REFLIST> | <REF> X3J3/94-014 A Proposal for Nested Wheres <REF> X3J3/93-167 <REF> ISO/IEC 1539:1991 <REF> High Performance Fortran </REFLIST> <SUBMITTED BY> Rich Bleikamp for X3J3/parallel subgroup bleikamp@convex.com, 214-306-6393 </SUBMITTED BY> <HISTORY> | <EVENT> Feb 94, meeting 128: | Draft 009 Specification, X3J3/94-014, submitted by Dick Hendrickson. <EVENT> May 93, meeting 125: Proposal X3J3/93-167 presented by Rich Bleikamp. </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 025 <TITLE> Pure User Functions and Subroutines <KEYWORDS> FUNCTIONS, SIDE EFFECTS, FORALL, PARALLELISM <STATUS> Registered <TARGET> <VERSION> 1 <REQUIREMENT> 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. <JUSTIFICATION> Requested by other Fortran related standards groups (HPFF). <COMPATIBILITY CONSIDERATIONS> None <REFLIST> <REF> X3J3/93-169 </REFLIST> <SUBMITTED BY> Rich Bleikamp for X3J3/parallel subgroup bleikamp@convex.com, 214-306-6393 </SUBMITTED BY> <HISTORY> <EVENT> Jul 93, WG5 meeting: WG5 tentatively approved for 1995 revision (resolution B9, item A4) <EVENT> May 93, meeting 125: Proposal X3J3/93-169 presented by Rich Bleikamp for X3J3/parallel subgroup </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 026 <TITLE> Directives <KEYWORDS> DIRECTIVE, COMPILER, COMMENT <STATUS> Archival <TARGET> <VERSION> 1 <REQUIREMENT> Provide a suggested DIRECTIVE syntax for Fortran programmers. <JUSTIFICATION> Users of Fortran would benefit from more commonality of directives, and better mechanisms for identifying directives which are not safe to ignore. <REFLIST> <REF> X3J3/93-171 <REF> Minutes from various Fortran 90 implementation symposia </REFLIST> <SUBMITTED BY> Rich Bleikamp for X3J3/parallel subgroup bleikamp@convex.com, 214-306-6393 </SUBMITTED BY> <HISTORY> <EVENT> Nov 93, meeting 127: Archived by unanimous consent. <EVENT> May 93, meeting 125: Proposal X3J3/93-171 presented by Rich Bleikamp. </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 027 <TITLE> Packaging Implementer Specific Intrinsics in MODULEs <KEYWORDS> INTRINSIC PROCEDURE, MODULE <STATUS> Registered <TARGET> <VERSION> 1 <REQUIREMENT> 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. <JUSTIFICATION> Facilitates extensions to Fortran environments by other standard bodies (e.g. HPFF, X3H5, POSIX). <COMPATIBILITY CONSIDERATIONS> None <REFLIST> <REF> X3J3/93-170 <REF> High Performance Fortran <REF> X3H5 document </REFLIST> <SUBMITTED BY> Rich Bleikamp for X3J3/parallel subgroup bleikamp@convex.com, 214-306-6393 </SUBMITTED BY> <HISTORY> <EVENT> May 93, meeting 125: Proposal X3J3/93-170 presented by Rich Bleikamp for X3J3/parallel subgroup </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 028 <TITLE> Binding to IEEE 754 <KEYWORDS> ARITHMETIC, FLOATING POINT, IEEE 754, BINDING <STATUS> Registered <TARGET> <VERSION> 1 <REQUIREMENT> 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.) <JUSTIFICATION> 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. <COMPATIBILITY CONSIDERATIONS> 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. <REFLIST> | <REF> Similar to item 32 of WG5 Requirements repository (N904). <REF> X3J3/93-162 <REF> ANSI/IEEE 754-1985, IEEE Standard for Binary Floating Point Arithmetic </REFLIST> <SUBMITTED BY> Keith H. Bierman, Keith.Bierman@eng.sun.com <HISTORY> <EVENT> 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). <EVENT> 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) <EVENT> May 93: Proposal X3J3/93-162 prepared by Keith Bierman </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 029 <TITLE> Interline Optimization <KEYWORDS> OPTIMIZATION, REORDER, BLOCKS <STATUS> Archival <TARGET> <VERSION> 1 <REQUIREMENT> 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 <REORDER> 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. <JUSTIFICATION> 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. <COMPATIBILITY CONSIDERATIONS> 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. <REFLIST> <REF> X3J3/93-132 </REFLIST> <SUBMITTED BY> Keith H. Bierman, Keith.Bierman@eng.sun.com <HISTORY> <EVENT> Nov 93, meeting 127: Archived by two-thirds vote (15-4) <EVENT> May 93: Proposal prepared by Keith Bierman </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 030 <TITLE> Variable Rank Arrays <KEYWORDS> ARRAY, RANK <STATUS> Registered <TARGET> <VERSION> 1 <REQUIREMENT> 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. <JUSTIFICATION> 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). <COMPATIBILITY CONSIDERATIONS> 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. <SUBMITTED BY> Dick Hendrickson, hendrick@acset.be <HISTORY> <EVENT> May 93: Proposal prepared by Dick Hendrickson </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 031 <TITLE> Varying Length Character with Declared Maximum <KEYWORDS> VARYING LENGTH, CHARACTER, MAXIMUM LENGTH | <STATUS> US TAG approved; ready for WG5 <TARGET> 1995 revision <VERSION> 1 <NOTE> Alternate proposal to X3J3/93-166 <REQUIREMENT> 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. <JUSTIFICATION> 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. <SUGGESTED IMPLEMENTATION> 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. <EXAMPLE> 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 </EXAMPLE> <COMPATIBILITY CONSIDERATIONS> No impact on existing code. <REFLIST> | <REF> Item ?? of WG5 Requirements repository (N904). <REF> X3J3/93-173 <REF> X3J3/93-166 <REF> ISO/IEC JTC1/SC22/WG5-N846 </REFLIST> <SUBMITTED BY> X3J3 <HISTORY> | <EVENT> Feb 94, US TAG meeting: | Forwarded to WG5 by unanimous consent of the US TAG, with a | recommendation to change the target to "2000 revision". <EVENT> Nov 93: Objection from J. Wagener to automatic US TAG approval. <EVENT> Nov 93, Meeting 127: Approved by X3J3 (12-7). <EVENT> May 93, Meeting 125: Proposal drafted by Janice Shepherd, X3J3/93-173. </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 032 <TITLE> POSIX Binding to Fortran 90 <KEYWORDS> POSIX, BINDING, FORTRAN 90, FORTRAN 77 <STATUS> Registered <TARGET> <VERSION> 1 <REQUIREMENT> Provide, in a separate, collateral standard, a binding for POSIX that makes use of the new features of Fortran 90. <JUSTIFICATION> 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. <COMPATIBILITY CONSIDERATIONS> 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. <REFLIST> <REF> POSIX Binding to Fortran 77 </REFLIST> <SUBMITTED BY> Len Moss, ljm@slac.stanford.edu, 415-926-3370 <HISTORY> <EVENT> 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). <EVENT> May 93: Proposal drafted by Len Moss </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 033 <TITLE> Object Oriented Fortran, OOF <KEYWORDS> OBJECT ORIENTED, OOF <STATUS> Registered <TARGET> <VERSION> 1 <REQUIREMENT> 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. <JUSTIFICATION> The OOPs paradigm is of growing importance in the programming community. <SUGGESTED IMPLEMENTATION> To be accomplished after WG5 authorization. <COMPATIBILITY CONSIDERATIONS> OOF must have the ability that a carefully coded library may be extended by a programmer using inheritance. <REFLIST> <REF> OOF View Graphs, X3J3/93-068 <REF> Object Oriented Fortran, OOF, X3J3/93-120 <REF> OOF, Making your favorite language object-oriented, X3J3/93-141 </REFLIST> <SUBMITTED BY> X3J3 Object Oriented Subcommittee <HISTORY> <EVENT> Jul 93, WG5 meeting: Investigation for 1995 revision requested (B9 Resolution, item C6) <EVENT> May 93, Meeting 125: Proposal for OOF requirement worked out; final draft submitted by Tom Lahey. <EVENT> 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. <EVENT> Nov 92, Meeting 123: X3J3 chartered the OOF Subcommittee (see X3J3/92-310). </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 034 <TITLE> Variable Repeat Specifiers in Formats <KEYWORDS> FORMAT <STATUS> Registered <TARGET> <VERSION> 1 <REQUIREMENT> 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. <JUSTIFICATION> This capability would enable tables to be defined by read statements, etc., and make the programs more flexible and easier to write. <REFLIST> <REF> Letter from Gedeminas Reinis dated 6 Jun 93 (proposer's title: "Repeatable Format Specifiers") </REFLIST> <SUBMITTED BY> Gedeminas Reinis 56 Woodhaven Dr. Rochester, New York 14625 </SUBMITTED BY> <HISTORY> <EVENT> 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). <EVENT> 14 Jun 93: Proposal received. </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 035 <TITLE> Specifying Default Precisions <KEYWORDS> DEFAULT REAL DOUBLE PRECISION KIND <STATUS> Registered <TARGET> <VERSION> 1 <REQUIREMENT> Allow a user to specify the precision used for the 'default real' and 'double precision real' types. <JUSTIFICATION> 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). <SUGGESTED IMPLEMENTATION> For illustration purposes only: <XMP> IMPLICIT (REAL,KIND=SELECTED_REAL_KIND(10,30)) (DEFAULT) </XMP> 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". <COMPATIBILITY CONSIDERATIONS> 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. <REFLIST> <REF> Email from John D. McCalpin dated 5 Jul 93 (proposer's title: "Specifying 'default real' and 'double precision real' precisions") </REFLIST> <SUBMITTED BY> John D. McCalpin, mccalpin@perelandra.cms.udel.edu, 302-831-3686 </SUBMITTED BY> <HISTORY> <EVENT> 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). <EVENT> 5 Jul 93: Proposal received. </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 036 <TITLE> MAXLOC and MINLOC To Accept CHARACTER Arguments <KEYWORDS> MAXLOC MINLOC CHARACTER <STATUS> Registered <TARGET> <VERSION> 1 <REQUIREMENT> Extend the ARRAY argument of the MAXLOC and MINLOC intrinsic functions to accept arrays of type CHARACTER. <JUSTIFICATION> 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. <SUBMITTED BY> Loren Meissner, meissner@lynx.cs.usfca.edu, 510-666-6328 </SUBMITTED BY> <HISTORY> <EVENT> 15 Aug 93: Proposal received. </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 037 <TITLE> Argument Passing Mechanism <KEYWORDS> ARGUMENT ASSOCIATION <STATUS> Registered <TARGET> <VERSION> 1 <NOTE> See also pFR 048 (Improve Interoperability between Fortran and ANSI C) </NOTE> <REQUIREMENT> 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. <JUSTIFICATION> 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) <SUGGESTED IMPLEMENTATION> 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. <ESTIMATED IMPACT> Vendors of Fortran language products would have to rewrite their Fortran syntax to provide this capability using the method approved by the standard. <REFLIST> <REF> ISO/IEC 1539:1991 12.4.1.1, 14.6.1.1 </REFLIST> <SUBMITTED BY> Craig T. Dedo 17130 W. Burleigh Place Brookfield, WI 53005 Phone: 414-783-5869, Email: 72341.1171@compuserve.com </SUBMITTED BY> <HISTORY> <EVENT> 03 Nov 93: Proposal received. </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 038 <TITLE> Complete Set of Compiler Directives <KEYWORDS> COMPILER DIRECTIVES, CONDITIONAL COMPILATION, PREPROCESSOR <STATUS> Registered <TARGET> <VERSION> 1 <NOTE> Similar to some combination of pFR 015 (Conditional Compilation) and pFR 026 (Directives) </NOTE> <REQUIREMENT> 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: <LIST> <ITEM> 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. <ITEM> 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. <ITEM> 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. <ITEM> Allow the inclusion or suppression of line numbering. <ITEM> Allow the user to output error message into the listing file if conditional testing produced error condition. <ITEM> 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. </LIST> 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. <JUSTIFICATION> 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) <ESTIMATED IMPACT> This requirement may require developers of Fortran processors to change the syntax of their existing compiler directives. <REFLIST> <REF> ISO/IEC 1539:1991 3.4 </REFLIST> <SUBMITTED BY> Craig T. Dedo 17130 W. Burleigh Place Brookfield, WI 53005 Phone: 414-783-5869, Email: 72341.1171@compuserve.com </SUBMITTED BY> <HISTORY> <EVENT> 03 Nov 93: Proposal received. </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 039 <TITLE> SYSTEM Command <KEYWORDS> OPERATING SYSTEM, SYSTEM COMMANDS, SUBPROCESS, USER EXIT <STATUS> Registered <TARGET> <VERSION> 1 <NOTE> See also pFR 032 (POSIX binding to Fortran 90) <REQUIREMENT> 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. <JUSTIFICATION> 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) <SUGGESTED IMPLEMENTATION> 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. <ESTIMATED IMPACT> Developers of processors which already have this type of capability may have to change the syntax of their Fortran code which supplies this capability. <SUBMITTED BY> Craig T. Dedo 17130 W. Burleigh Place Brookfield, WI 53005 Phone: 414-783-5869, Email: 72341.1171@compuserve.com </SUBMITTED BY> <HISTORY> <EVENT> 03 Nov 93: Proposal received. </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 040 <TITLE> Obtain the Command Line <KEYWORDS> COMMAND LINE, OPERATING SYSTEM <STATUS> Registered <TARGET> <VERSION> 1 <NOTE> Similar to pFR 16 (Command Line Arguments and Environmental Variables); see also pFR 032 (POSIX binding to Fortran 90) </NOTE> <REQUIREMENT> The new standard should provide for a capability to obtain the entire command line when the program starts up. <JUSTIFICATION> 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) <SUGGESTED IMPLEMENTATION> 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. <ESTIMATED IMPACT> Vendors of Fortran language products would have to rewrite their Fortran syntax to provide this capability using the method approved by the standard. <SUBMITTED BY> Craig T. Dedo 17130 W. Burleigh Place Brookfield, WI 53005 Phone: 414-783-5869, Email: 72341.1171@compuserve.com </SUBMITTED BY> <HISTORY> <EVENT> 03 Nov 93: Proposal received. </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 041 <TITLE> Obtain Program Startup Command <KEYWORDS> COMMAND NAME, PATH, OPERATING SYSTEM <STATUS> Registered <TARGET> <VERSION> 1 <NOTE> 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) </NOTE> <REQUIREMENT> 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]. <JUSTIFICATION> 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) <SUGGESTED IMPLEMENTATION> 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. <ESTIMATED IMPACT> Vendors of Fortran language products would have to rewrite their Fortran syntax to provide this capability using the method approved by the standard. <SUBMITTED BY> Craig T. Dedo 17130 W. Burleigh Place Brookfield, WI 53005 Phone: 414-783-5869, Email: 72341.1171@compuserve.com </SUBMITTED BY> <HISTORY> <EVENT> 03 Nov 93: Proposal received. </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 042 <TITLE> Indexed Files <KEYWORDS> I/O, INDEXED FILES, KEYED ACCESS <STATUS> Registered <TARGET> <VERSION> 1 <REQUIREMENT> The new standard should require the support of indexed files and provide for standard access to indexed files. <JUSTIFICATION> 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) <SUGGESTED IMPLEMENTATION> 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. <ESTIMATED IMPACT> Vendors of Fortran language products would have to rewrite their Fortran syntax to provide this capability using the method approved by the standard. <REFLIST> <REF> ISO/IEC 1539:1991 9.2.1.2, 9.3.4.3, 9.4.1, 9.6.1 </REFLIST> <SUBMITTED BY> Craig T. Dedo 17130 W. Burleigh Place Brookfield, WI 53005 Phone: 414-783-5869, Email: 72341.1171@compuserve.com </SUBMITTED BY> <HISTORY> <EVENT> 03 Nov 93: Proposal received. </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 043 <TITLE> OOP Capabilities <KEYWORDS> OBJECT ORIENTED <STATUS> Registered <TARGET> <VERSION> 1 <NOTE> Related to pFR 33 (Object Oriented Fortran, OOF) <REQUIREMENT> 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. <JUSTIFICATION> 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) <ESTIMATED IMPACT> This requirement has no impact on existing Fortran code. The cost of providing this capability would probably be fairly high. <SUBMITTED BY> Craig T. Dedo 17130 W. Burleigh Place Brookfield, WI 53005 Phone: 414-783-5869, Email: 72341.1171@compuserve.com </SUBMITTED BY> <HISTORY> <EVENT> 03 Nov 93: Proposal received. </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 044 <TITLE> Unsigned INTEGER Data Type <KEYWORDS> DATA TYPE, UNSIGNED INTEGER <STATUS> Registered <TARGET> <VERSION> 1 <REQUIREMENT> 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. <JUSTIFICATION> 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) <SUGGESTED IMPLEMENTATION> 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. <ESTIMATED IMPACT> 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. <REFLIST> <REF> ISO/IEC 1539:1991 4.3.1.1 </REFLIST> <SUBMITTED BY> Craig T. Dedo 17130 W. Burleigh Place Brookfield, WI 53005 Phone: 414-783-5869, Email: 72341.1171@compuserve.com </SUBMITTED BY> <HISTORY> <EVENT> 03 Nov 93: Proposal received. </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 045 <TITLE> Unicode Character Set Support <KEYWORDS> UNICODE, CHARACTER SET <STATUS> Registered <TARGET> <VERSION> 1 <REQUIREMENT> The new Fortran standard should require support for the Unicode character set. <JUSTIFICATION> 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) <ESTIMATED IMPACT> This requirement has no impact on existing Fortran code. I would expect implementation cost to be minimal. <REFLIST> <REF> ISO/IEC 1539:1991 4.3.2.1 </REFLIST> <SUBMITTED BY> Craig T. Dedo 17130 W. Burleigh Place Brookfield, WI 53005 Phone: 414-783-5869, Email: 72341.1171@compuserve.com </SUBMITTED BY> <HISTORY> <EVENT> 03 Nov 93: Proposal received. </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 046 <TITLE> Row Major Arrays <KEYWORDS> ARRAYS, SUBSCRIPT ORDER, ROW-MAJOR <STATUS> Registered <TARGET> <VERSION> 1 <REQUIREMENT> 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. <JUSTIFICATION> 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) <SUGGESTED IMPLEMENTATION> This could be done by defining a ROW_MAJOR keyword which would declare an array to have row-major storage allocation. <ESTIMATED IMPACT> This requirement has no impact on existing Fortran code. Column-major arrays would still be supported. <REFLIST> <REF> ISO/IEC 1539:1991 6.2.2.2 </REFLIST> <SUBMITTED BY> Craig T. Dedo 17130 W. Burleigh Place Brookfield, WI 53005 Phone: 414-783-5869, Email: 72341.1171@compuserve.com </SUBMITTED BY> <HISTORY> <EVENT> 03 Nov 93: Proposal received. </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 047 <TITLE> File Sharing Modes <KEYWORDS> I/O, SHARED ACCESS <STATUS> Registered <TARGET> <VERSION> 1 <REQUIREMENT> 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: <LIST> <ITEM> Exclusive use by this unit <ITEM> Reading by others, but not writing <ITEM> Writing by others but not reading <ITEM> Permit full access by others </LIST> <JUSTIFICATION> 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) <SUGGESTED IMPLEMENTATION> 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: <TABLE> 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 </TABLE> <ESTIMATED IMPACT> 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. <REFLIST> <REF> ISO/IEC 1539:1991 9.3.4.8 </REFLIST> <SUBMITTED BY> Craig T. Dedo 17130 W. Burleigh Place Brookfield, WI 53005 Phone: 414-783-5869, Email: 72341.1171@compuserve.com </SUBMITTED BY> <HISTORY> <EVENT> 03 Nov 93: Proposal received. </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 048 <TITLE> Improve Interoperability between Fortran and ANSI C <KEYWORDS> INTERFACE, INTEROPERABILITY, ANSI C <STATUS> Registered <TARGET> <VERSION> 1 <NOTE> Counter proposal to pFR 037 (Argument Passing Mechanism) <REQUIREMENT> 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. <JUSTIFICATION> 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. <SUBMITTED BY> Stan Whitlock for X3J3/JOR. </SUBMITTED BY> <HISTORY> <EVENT> Nov 93, meeting 127: Proposal drafted. </HISTORY> </FORTREQ> ---------------------------------------------------------------------- | <FORTREQ> | <NUMBER> 049 | <TITLE> Generalize Constructors Into Generic Procedures | <KEYWORDS> DERIVED TYPE, CONSTRUCTOR, GENERIC PROCEDURE | <STATUS> Registered | <TARGET> | <VERSION> 1 | | <REQUIREMENT> | Allow users the freedom to write their own (generic) versions of | constructors; further, allow the use of procedure-call syntax when | using constructors. | | <JUSTIFICATION> | As we look at filling out the object-oriented capabilities of Fortran, | we encounter some small shortcomings that are easily remedied. | | When a constructor is supplied for a user-defined data type in Fortran | or other languages, it bears the name of the type. This is usual and | expected functionality. Unfortunately: | | - In Fortran, currently, the constructor is a special thing, not a | procedure. In particular, the keyword form of an actual argument | list is not available. Users are reduced to a positional form, | which hampers readability. | | - users cannot currently provide their own generic instances of | constructors bearing the preferred name. This is essential for | various abstract-data-type situations, in which the user is | expected to neither know nor care about the precise identity of | all the fields. | | - for a private type, no constructor is provided by the language at | all. | | Users should not have to suffer these shortcomings. | | <SUGGESTED IMPLEMENTATION> | Phase 1: Constructor syntax | Change the syntax requirements on a constructor so that it can be | written in the same format as a procedure call; in particular, allow | argument keywords and out-of-order specification. The field names | would form the keywords set. (Target for this phase: 1995 revision.) | | Phase 2: Generic constructor | Currently, a structure constructor forms a special, separate | category. Change the description so that "A derived-type definition | implicitly defines a corresponding ..." generic function which serves | as a constructor for the type (Section 4.4.4 [37/2]). | | There will be rationale comment: this allows a user to provide his/her | own generic functions that serve as constructors. | | In order to make this work, we need to slightly change the name class | rules. (See a discussion of this in section 5 of document | X3J3/94-042r1, "Parameterized Data Types".) This change would allow | the coexistence of types and generic functions with the same name. | | Note that this change does not introduce any new ambiguity into the | language. R701 shows primary as ... function-reference OR | structure-constructor. These two are syntactically the same, so | moving the constructor from one category to the other won't break | anything. Lawrie Schonfelder points out the restricted nature of | the use of type names: they only appear after the keyword TYPE or in | parentheses after TYPE. | | <ESTIMATED IMPACT> | This can be done in two phases. The first affects only the actual | usage of a constructor as currently defined, and has not outside | interactions. The second requires a change to the name-class rules, | but this is benign. No existing programs would be invalidated. | | <REFLIST> | <REF> X3J3/94-107 Generalization of derived type constructors into | Generic Procedures | <REF> X3J3/94-108 Generalization of derived type constructors into | Generic Procedures | </REFLIST> | | <SUBMITTED BY> | David Levine for X3J3/OOF (email: drlevine@apollo.hp.com) | </SUBMITTED BY> | | <HISTORY> | <EVENT> Feb 93, meeting 128: | Proposals drafted (94-107 and 94-108). | </HISTORY> | | </FORTREQ> ----------------------------------------------------------------------