###################################################################### # # # X3J3/95-004r1 # # Journal Of Requirements # # (Full Version) # # # # Oct 1995 # # # ###################################################################### 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: Stan Whitlock Digital Equipment Corp. ZK02-3/N30 110 Spit Brook Rd. Nashua, NH 03062 email: x3j3-jor@ncsa.uiuc.edu 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 | 000 US 2000 Minor Technical Enhancements 001 Arch Bit Data Type, Non-string 002 Reg Variant Derived Type 003 Reg Array Components of Array Structures 004 Sat 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 2000 Nesting of Internal Procedures 011 Arch Internal Procedure Names as Actual Arguments | 012 US 2000 Condition Handling 013 Sat Pointer Initialization 014 Arch Language Management | 015 US 2000 Conditional Compilation | 016 US 2000 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 Sat User Defined Elemental Functions 021 Sat Obsolesce Fixed Source Form 022 Reg Keep It Simple, Make It Fine 023 Sat User Defined Intrinsic Functions 024 Sat 1995 Nested WHERE Statements 025 Sat 1995 Pure User Functions and Subroutines | 026 US 2000 Directives | 027 US 2000 Packaging Implementer Specific Intrinsics in MODULEs 028 US Coll Binding to IEEE 754 029 Arch Interline Optimization 030 Reg Variable Rank Arrays | 031 US 2000 Varying Length Character with Declared Maximum | 032 US 2000 POSIX Binding to Fortran 90 | 033 US 2000 Object Oriented Fortran, OOF | 034 US 2000 Variable Repeat Specifiers in Formats | 035 US 2000 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 US 2000 Unsigned INTEGER Data Type 045 Reg Unicode Character Set Support 046 Reg Row Major Arrays 047 Reg File Sharing Modes | 048 US 2000 Improve Interoperability between Fortran and ANSI C 049 X3J3 2000 Generalize Constructors Into Generic Procedures 050 Reg Intrinsic and User-defined Specific and Generic Names 051 Reg English Words As Function Names 052 Reg Extend .EQ. And .NE. To Logical Values 053 US Regularize KIND= Arguments Of Intrinsic Functions 054 Reg Complete Set of Explicit Attributes 055 Reg Array Organization Attributes 056 Reg Ranges Specified by Start and Length 057 Reg Explicit Scope Identification in References (Extend %) | 058 US 2000 Regularize Handling of Pointer Arguments | 059 US 2000 Pointers to Procedures 060 Reg Pointer Association Classes 061 Reg Composable FORALL Functionality 062 Reg Composable WHERE Facility 063 Reg Symmetric Linkage of Argument Attributes 064 Reg Symbolic Names for Specification Expressions 065 Reg POINTER Objects as Operands 066 Reg Generic COUNT_RATE Argument for SYSTEM_CLOCK | 067 US 2000 Greater than 7 Array Dimensions 068 Reg Generic specification on the END INTERFACE statement 069 Reg Intrinsic function CONCAT 070 Reg Extended indexing capabilities 071 Reg Linear array access 072 Reg Intrinsic function REVERSE 073 Reg Multi-dimensional transpose 074 Reg Spaces should no longer be allowed in names | 075 US 2000 Remove limitation on statement length 076 Reg Need EXPM1 and LOGP1 intrinsics | 077 US 2000 Processor Dependent Features List | 078 Reg Standardized Handling of Modules | 079 Reg Asynchronous I/O | 080 US 2000 Asynchronous I/O (proposed HPFF work) | 081 US 2000 PRIVATE and SHARED variables for TASK parallelism | 082 Reg Interval Arithmetic Support ###################################################################### | | 000 | Minor Technical Enhancements | <KEYWORDS> | <STATUS> US TAG approved; ready for WG5 | <TARGET> 2000 revision | <SUBGROUP> | <VERSION> 1 | | <REQUIREMENT> | This requirement is a placeholder to allow the development body to add | small features and enhancements to the Fortran standard as it deems | appropriate within the charter and schedule of the current draft effort. | </REQUIREMENT> | | <JUSTIFICATION> | This allows the development group to get informal agreement on adding | small features to the standard without the delay of going through the | formal requirements approval process | </JUSTIFICATION> | | <SUGGESTED IMPLEMENTATION> | </SUGGESTED IMPLEMENTATION> | | <ESTIMATED IMPACT>Submitter says: | No negative impact. | </ESTIMATED IMPACT> | | <SUBMITTED BY> | Stan Whitlock, JOR | </SUBMITTED BY> | | <HISTORY> | <EVENT> Aug 95, meeting 134: | Submitted, approved by US TAG for F2000 as high priority | </HISTORY> | | </FORTREQ> | ------------------------------------------------------------------------------- <FORTREQ> <NUMBER> 001 <TITLE> Bit Data Type, Non-string <KEYWORDS> BIT, INTRINSIC, DATA TYPE <STATUS> Archival <TARGET> <SUBGROUP> <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> <SUBGROUP> /OOF <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> <SUBGROUP> /OOF <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> Satisfied <TARGET> 1995 revision <SUBGROUP> /parallel <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> Jun 95, meeting 133: Status changed to "Satisfied in F95", 95-153r1, approved by unanimous consent. <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> <SUBGROUP> <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> <SUBGROUP> <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> <SUBGROUP> <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> <SUBGROUP> <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> <SUBGROUP> <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> 2000 revision <SUBGROUP> /JOR <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> Aug 95, meeting 134: | Approved by US TAG for F2000 as medium priority <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> <SUBGROUP> <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 <SUBGROUP> /JOR <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> Aug 95, meeting 134: | Approved by US TAG for F2000 as high priority <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> Satisfied <TARGET> 1995 Revision <SUBGROUP> /OOF <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> Jun 95, meeting 133: Status changed to "Satisfied in F95", 95-153r1, approved by unanimous consent. <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> Archival <TARGET> <SUBGROUP> /JOR <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> Aug 94, meeting 130: Archived by unanimous consent. <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> 2000 revision <SUBGROUP> /JOR <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> Aug 95, meeting 134: | Approved by US TAG for F2000 as high priority <EVENT> Jun 95, meeting 133: Remove "target 1995 revision", 95-153r1, 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> 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> 2000 revision <SUBGROUP> /OSCI <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> Aug 95, meeting 134: | Approved by US TAG for F2000 as high priority <EVENT> Jun 95, meeting 133: Remove "target 1995 revision", 95-153r1, approved by unanimous consent. <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 <SUBGROUP> /JOR <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> Aug 95, meeting 134: | Approved by US TAG for F2000 as medium priority <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 <SUBGROUP> /OOF <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> <SUBGROUP> /OOF <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> Satisfied <TARGET> 1995 Revision <SUBGROUP> /parallel <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> Jun 95, meeting 133: Status changed to "Satisfied in F95", 95-153r1, approved by unanimous consent. <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> Satisfied <TARGET> 1995 Revision <SUBGROUP> /JOR <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> Jun 95, meeting 133: Status changed to "Satisfied in F95", 95-153r1, approved by unanimous consent. <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> <SUBGROUP> /JOR <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> Satisfied <TARGET> 1995 Revision <SUBGROUP> /JOR <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> Jun 95, meeting 133: Status changed to "Satisfied in F95", 95-153r1, approved by unanimous consent. <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> Satisfied <TARGET> 1995 Revision <SUBGROUP> /parallel <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> Jun 95, meeting 133: Status changed to "Satisfied in F95", 95-153r1, approved by unanimous consent. <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> Satisfied <TARGET> 1995 Revision <SUBGROUP> /parallel <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> Jun 95, meeting 133: Status changed to "Satisfied in F95", 95-153r1, approved by unanimous consent. <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> US TAG approved; ready for WG5 | <TARGET> 2000 revision <SUBGROUP> /JOR <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> Aug 95, meeting 134: | Unarchived, approved by US TAG for F2000 as medium priority <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> US TAG approved; ready for WG5 | <TARGET> 2000 revision <SUBGROUP> /JOR <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 <REF> Fortran 90 Defect Item 122 </REFLIST> <SUBMITTED BY> Rich Bleikamp for X3J3/parallel subgroup bleikamp@convex.com, 214-306-6393 </SUBMITTED BY> <HISTORY> | <EVENT> Aug 95, meeting 134: | Approved by US TAG for F2000 as medium priority <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> US TAG approved; ready for WG5 <TARGET> Collateral Standard <SUBGROUP> /JOR <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> <SUBGROUP> /JOR <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> <SUBGROUP> /OOF <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> 2000 revision <SUBGROUP> /JOR <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 34 of WG5 Requirements repository (N970). <REF> X3J3/93-173 <REF> X3J3/93-166 <REF> ISO/IEC JTC1/SC22/WG5-N846 </REFLIST> <SUBMITTED BY> X3J3 <HISTORY> | <EVENT> Aug 95, meeting 134: | Approved by US TAG for F2000 as medium priority <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> US TAG approved; ready for WG5 | <TARGET> 2000 revision <SUBGROUP> /OSCI <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> Aug 95, meeting 134: | Approved by US TAG for F2000 as medium priority <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> US TAG approved; ready for WG5 | <TARGET> 2000 revision <SUBGROUP> /OOF <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> Aug 95, meeting 134: | Approved by US TAG for F2000 as medium priority <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> US TAG approved; ready for WG5 | <TARGET> 2000 revision <SUBGROUP> /JOR <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> Aug 95, meeting 134: | Approved by US TAG for F2000 as medium priority <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> US TAG approved; ready for WG5 | <TARGET> 2000 revision <SUBGROUP> /JOR <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> Aug 95, meeting 134: | Approved by US TAG for F2000 as medium priority <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> <SUBGROUP> /edit <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> <SUBGROUP> /JOR <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> <SUBGROUP> /JOR <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> <SUBGROUP> /OSCI <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> <SUBGROUP> /OSCI <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> <SUBGROUP> /OSCI <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> <SUBGROUP> /JOR <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> <SUBGROUP> /OOF <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> US TAG approved; ready for WG5 <TARGET> 2000 revision <SUBGROUP> /JOR <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> Aug 95, meeting 134: | Approved by US TAG for F2000 as medium priority <EVENT> 03 Nov 93: Proposal received. </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 045 <TITLE> Unicode Character Set Support <KEYWORDS> UNICODE, CHARACTER SET <STATUS> Registered <TARGET> <SUBGROUP> /JOR <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> <SUBGROUP> /OSCI <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> <SUBGROUP> /OSCI <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> US TAG approved; ready for WG5 <TARGET> 2000 revision <SUBGROUP> /OSCI <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> Aug 95, meeting 134: | Approved by US TAG for F2000 as high priority <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> X3J3 approved; ready for US TAG <TARGET> 2000 revision <SUBGROUP> /OOF <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> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 050 <TITLE> Intrinsic and User-defined Specific and Generic Names <KEYWORDS> INTRINSIC, SPECIFIC, GENERIC, NAMES <STATUS> Registered <TARGET> <SUBGROUP> /JOR <VERSION> 1 <NOTE> Proposer's title: "Remove inconsistency in treatment of intrinsic and user-defined specific and generic names". </NOTE> <REQUIREMENT> Permit the specific name of a user-defined procedure to be passed as an actual argument even if it is the same as the generic name, just as is permitted in Fortran 77 and Fortran 90 for intrinsic functions. <PROBLEM DESCRIPTION> FORTRAN 77 introduced the concept of generic and specific names for intrinsic functions. It requires that wherever an intrinsic function name is passed as an actual argument it must be in the form of the specific name. Thus, when ABS is passed as an actual argument, it is interpreted as the specific, rather than the generic, name. Fortran 90 allows users also to define generic and specific names. Once again, only specific names may be passed as actual arguments. However, the penultimate constraint in 12.4.1 [172/7f] categorically prohibits a generic name being passed as an actual argument. Thus, if a generic name is identical to a specific name, it cannot be passed at all as it is interpreted as a generic name. As an example <XMP> subroutine test INTERFACE f FUNCTION f(x) REAL f, x END function f END INTERFACE call thing (f) ! f is generic (as well as specific) ! and cannot be used end subroutine test </XMP> is illegal. Thus, there is an inconsistency between the interpretation of F77-style generic names and of f90-style generic names. The code above should be made legal by interpreting the use of 'f' in the actual argument to be a specific name. A possible solution is to add 'unless it is also a specific name' at the end of the penultimate constraint of 12.4.1 [172/8] in Fortran 90. <JUSTIFICATION> Inconsistencies in the language breach the Principle of Least Surprise. <SUBMITTED BY> Michael Metcalf, metcalf@cern.ch <HISTORY> <EVENT> Mar 94: Proposal submitted via email. </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 051 <TITLE> English Words As Function Names <KEYWORDS> ENGLISH, FUNCTION NAME, ISHFT <STATUS> Registered <TARGET> <SUBGROUP> /edit <VERSION> 1 <REQUIREMENT> 1. That new function names be English words. 2. That, in particular, the function name ISHFT be changed to SHIFT 3. That a specific name be available for left shift and right shift (e.g. SHL, SHR or SHIFTL, SHIFTR) <JUSTIFICATION> 1. English words are more appropriate, aid readability, and are easier to use and to recall their purpose. 2. The word ISHFT is difficult to recall, and leads to misspellings. 3. That whether the shift is right or left (which depends on the negative or positive parameter supplied) is not clear from a perusal of a program. <SUBMITTED BY> Robin Vowels, rav@cs.rmit.oz.au <HISTORY> <EVENT> Mar 94: Proposal submitted via email. </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 052 <TITLE> Extend .EQ. And .NE. To Logical Values <KEYWORDS> LOGICAL OPERATORS, RELATIONAL OPERATORS, .EQ., ==, .NE., /= <STATUS> Registered <TARGET> <SUBGROUP> /OOF <VERSION> 1 <REQUIREMENT> Regularize the treatment of equality and nonequality, so that the same relational operators (i.e., .EQ., ==, .NE. and /=) may be used for all types. <JUSTIFICATION> Fortran's treatment of equality for LOGICAL expressions is a HACK. The operators .EQV. and .NEQV. should NEVER have been invented. The concept of equality is independent of data type, and special-purpose symbols restricted to one particular intrinsic data type greatly damage the regularity of the language. <SUBMITTED BY> Carlie J. Coats, Jr., Ph.D. phone (919)248-9241 MCNC Environmental Programs fax (919)248-9245 3021 Cornwallis Rd. RTP, NC 27709-2889 xcc@epavax.rtpnc.epa.gov </SUBMITTED BY> <HISTORY> <EVENT> Mar 94: Email comment recast as pFR and registered. <EVENT> Nov 93: Email commenting on subject received. </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 053 <TITLE> Regularize KIND= Arguments Of Intrinsic Functions <KEYWORDS> KIND, INTRINSIC, CONVERSION, FUNCTION <STATUS> US TAG approved; ready for WG5 <TARGET> <SUBGROUP> /edit <VERSION> 1 <REQUIREMENT> Adopt a simple rule to decide which intrinsic functions should have KIND= arguments, and apply it consistently. <JUSTIFICATION> Recently a number of people on comp.lang.fortran have commented on the fact that INT, AINT, NINT, and ANINT all have KIND= arguments, but FLOOR and CEILING, which appear to users to be quite similar, do not. Though some contend that the former are all "conversion" functions while the latter are not, this distinction is, at best, extremely subtle. A rule that is simple and more obvious is needed so that users will be able to easily remember which functions have the KIND= argument. <SUBMITTED BY> Len Moss, ljm@slac.stanford.edu <HISTORY> <EVENT> Jun 95, meeting 133: Remove "target 1995 revision", 95-153r1, approved by unanimous consent. <EVENT> Apr 94: Proposal drafted in response to comp.lang.fortran thread. </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 054 <TITLE> Complete Set of Explicit Attributes <KEYWORDS> SPECIFICATION, ATTRIBUTES <STATUS> Registered <TARGET> <SUBGROUP> /OOF <VERSION> 1 <REQUIREMENT> Provide a means of explicitly declaring attributes that are inferred from the lack of contrary declarations or usage. Thus, one should be able to explicitly declare that a name denotes a variable, that it is scalar, that it does not have the SAVE attribute (and is not a dummy argument or function result), that no INTENT restrictions are being asserted, that a variable is not be mapped into COMMON or EQUIVALENCED, etc. <JUSTIFICATION> In larger scoping units, it can be time consuming to try to verify the absence of contrary declarations or usage. Also, the accidental introduction of contrary declarations or usage can sometime produce undiagnosed errors that are difficult to locate. If a user chooses to declare the complete attributes of entities, these problems can be avoided. <SUGGESTED IMPLEMENTATION> Follow the example of PUBLIC and PRIVATE in allowing explicitly stated defaults. Thus, for example, if DISCARD is the attribute name meaning not SAVEd or dummy, then the statement SAVE should be interpreted as making the default storage class SAVE, with the possibility of explicitly declaring some variable DISCARD, and the statement DISCARD is an explicit assertion of the default (reassuring the vendor that this code really understands the implications of not saving variables). <ESTIMATED IMPACT> The direct description of these attributes should be relatively self contained. The description of the defaulting method, if done generally, might imply the need to eliminate text from the description of PUBLIC, PRIVATE, and SAVE. The existence of names for some of these attributes will provide opportunities to clarify test elsewhere. (Author's assessment: some or all of this could be done in the F95 context.) <SUBMITTED BY> Kurt W. Hirchert, hirchert@ncsa.uiuc.edu <HISTORY> <EVENT> April 93: Initial proposal </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 055 <TITLE> Array Organization Attributes <KEYWORDS> ARRAY, ATTRIBUTE, ORGANIZATION <STATUS> Registered <TARGET> <SUBGROUP> /parallel <VERSION> 1 <NOTE> Proposer's title: "Array organization attributes consecutive, uniform, linear, and general" </NOTE> <REQUIREMENT> Make the concept of array organization explicit. Define the organizations resulting from the various forms of array declaration and reference. Express restrictions and constraints in terms of the organization rather than the declarations and reference forms that imply them. Where appropriate, allow the user to declare that memory organization is being used other than that which would normally be implied. <JUSTIFICATION> The current approach is descriptively error prone and provides minimal guidance for extensions. Overriding defaults can allow for more efficient code generation. For example, declaring that a pointer is restricted to describing consecutive arrays will allow both a more compact representation of the pointer itself and the generation of more efficient code in references to the array. Similarly, declaring an explicit-shaped array to be linear rather than consecutive allows the processor to avoid copy-in/copy-out when associating an array section as an actual argument. <SUGGESTED IMPLEMENTATION> An array is _consecutive_ if its array elements, taken in standard order, are uniformly spaced at a distance that depends only on the element attributes. Knowing the location of one element in a consecutive array provides sufficient information to derive the location of all the rest. All arrays in FORTRAN 77 were consecutive. (So are allocatable arrays.) An array is _uniform_ if its array elements, taken in standard order, are uniformly spaced. Knowing the location of two elements in a uniform array provides sufficient information to derive the location of all the rest. Designators of the forms "consecutive_array%component" and "consecutive_array(index,:)" are uniform. An array is _linear_ if its array elements are uniformly spaced along each dimension. For an array of rank n, it takes knowledge of the location of n+1 elements to provide sufficient information to derive the location of all the rest. Assumed-shape arrays and pointers are linear. An array is _general_ if none of the above properties is (can be) asserted. No collection of elements is sufficiently large to predict the location of an element not in that collection. Array references with vector-valued subscripts are general. (If we allowed them, arrays of pointer references would also be general.) <ESTIMATED IMPACT> Final text might possibly be simpler than current text, but significant text changes would be necessary to get there. (Author's assessment: too large to complete in context of F95) <SUBMITTED BY> Kurt W. Hirchert, hirchert@ncsa.uiuc.edu <HISTORY> <EVENT> April 93: Initial proposal </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 056 <TITLE> Ranges Specified by Start and Length <KEYWORDS> RANGE, SEQUENCE, START, END, LENGTH <STATUS> Registered <TARGET> <SUBGROUP> /JOR <VERSION> 1 <REQUIREMENT> In each context in which a range or sequence is specified using a start and end value, provide an alternative to use a start value and length. <JUSTIFICATION> In some applications, length is a constant or naturally derived value, and the end value is derived from it. In such problems, specifying a range in terms of start and end values tends to obscure the logic of the program. <SUGGESTED IMPLEMENTATION> In each context where one is allowed to write "start : end", allow also "start +: length". [This includes the alternative of "start +: length : incr" for "start : end : incr".] In each context where one is allowed to write "start , end", allow also "start +, length". [This is _ugly_, but consistent with the above.] <ESTIMATED IMPACT> The number of places that need additions is moderate. The text required at each location could be kept small through the use of equivalences like "start +: length : incr" means the same as "start : start+(length-1)*incr : incr". [In the long run, we might prefer to describe the equivalence in the reverse direction.] (Author's assessment: could reasonably be done in the context of F95.) <SUBMITTED BY> Kurt W. Hirchert, hirchert@ncsa.uiuc.edu <HISTORY> <EVENT> April 93: Initial proposal </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 057 <TITLE> Explicit Scope Identification in References (Extend %) <KEYWORDS> SCOPE, HOST ASSOCIATION, USE ASSOCIATION <STATUS> Registered <TARGET> <SUBGROUP> /OOF <VERSION> 1 <REQUIREMENT> One possible description of the syntax "A%B" in Fortran 90 is that "A" denotes an instance of a scoping unit (in Fortran 90, the scoping unit of the type definition) and that "B" is then interpreted in that scope. Extend that concept by allowing other possibilities for "A". <JUSTIFICATION> Many of the benefits of the proposal stem from the opportunity to make the standard easier to understand. In a few cases, this also provides the opportunity to write things that are not expressible in current notation. <SUGGESTED IMPLEMENTATION> Allow access to names in one's host scoping unit by omitting "A". Host association is then the textual convention by which "NAME" comes to denote the same thing as "%NAME" when no local definition is provided. Access to host objects is never totally blocked. [Note that "%%NAME" would mean interpret "%NAME" in one's host, i.e., interpret "NAME" in the host of one's host.] Allow "A" to be the name of a module. Thus USE mod,ONLY: rename=>orig_name has the effect of making the local use of "rename" the same as using "mod%orig_name". A USE statement must be present to establish that name is the name of a module. All public entities of the module may be accessed this way. The ONLY: clause serves only to limit the entities that are given a local name. <ESTIMATED IMPACT> Impact on the document appears to be extensive. Impact on conforming processors is significantly smaller: processors must be able to recognize the new notation, but the code generated is no different from that which would have been generated had the entity been denoted through host or use association instead of direct scope identification. (Author's assessment: the document changes make this too large to do in the context of F95.) <SUBMITTED BY> Kurt W. Hirchert, hirchert@ncsa.uiuc.edu <HISTORY> <EVENT> April 93: Initial proposal </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 058 <TITLE> Regularize Handling of Pointer Arguments <KEYWORDS> POINTER, DUMMY ARGUMENT, ASSOCIATION, EXPRESSION, INTENT | <STATUS> US TAG approved; ready for WG5 | <TARGET> 2000 revision <SUBGROUP> /OOF <VERSION> 1 <REQUIREMENT> Treat pointer dummy arguments more like other dummy arguments. <JUSTIFICATION> Reduce surprise. Make operations involving pointers easier to express. <SUGGESTED IMPLEMENTATION> Allow INTENT specifications on pointer arguments, with the INTENT restrictions applying to the association of the pointer, not the value of the object with which the pointer is associated. Allow "pointer expressions" to be associated with dummy pointers subject to the same restrictions that apply to ordinary expression and dummy variables: the association denoted by the expression is evaluated once and then does not change even if the entities comprising it are modified, and the association of the dummy pointer may not be redefined. Treat a pointer-valued function reference as a "pointer expression" when it is being associated with a dummy pointer. Treat a parenthesized pointer reference as a "pointer expression" when it is being associated with a dummy pointer. Treat a variable with the target attribute as a "pointer expression" (a "pointer constant", if you will) when it is being associated with a dummy pointer. <ESTIMATED IMPACT> Most of the textual impact should be in the area describing allowed argument associations. Impact on conforming processors should be similarly contained. (Author's assessment: this is possible in the context of Fortran 95.) <SUBMITTED BY> Kurt W. Hirchert, hirchert@ncsa.uiuc.edu <HISTORY> | <EVENT> Aug 95, meeting 134: | Approved by US TAG for F2000 as medium priority <EVENT> April 93: Initial proposal </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 059 <TITLE> Pointers to Procedures <KEYWORDS> POINTER, PROCEDURE, INTERFACE BLOCK | <STATUS> US TAG approved; ready for WG5 | <TARGET> 2000 revision <SUBGROUP> /OOF <VERSION> 1 <REQUIREMENT> Provide pointers which are associated with procedures rather than variables. <JUSTIFICATION> Such pointers would be a more convenient alternative to dummy procedures in many situations because they could be set once rather than having to be respecified in the argument list of each operation. <SUGGESTED IMPLEMENTATION> Procedure pointers would be declared with a POINTER declaration plus an interface block (or EXTERNAL statement?). The procedures which could be associated with such a pointer are exactly those that could be associated with a dummy procedure having the same interface. Procedure pointers would be allowed in derived types. There would be no ALLOCATE for procedure pointers. Pointers to procedures associated with an instance of a scoping unit would be valid only for the lifetime of that instance. <ESTIMATED IMPACT> Because of the similarity to dummy procedures, most of the text changes would be straightforward. Code changes in conforming processors would likely be similarly straightforward. (Author's assessment: doable in the context of F95, but only barely.) <SUBMITTED BY> Kurt W. Hirchert, hirchert@ncsa.uiuc.edu <HISTORY> | <EVENT> Aug 95, meeting 134: | Approved by US TAG for F2000 as medium priority <EVENT> April 93: Initial proposal </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 060 <TITLE> Pointer Association Classes <KEYWORDS> POINTER, TARGET, ASSOCIATION <STATUS> Registered <TARGET> <SUBGROUP> /parallel <VERSION> 1 <REQUIREMENT> Provide a mechanism to limit the targets to which a pointer may point or the pointers which may point to a target. <JUSTIFICATION> Use of this mechanism would reduce the optimization impact of using pointers. <SUGGESTED IMPLEMENTATION> Extend POINTER attribute to allow specification of the targets with which the pointer can be associated. Extend the TARGET attribute to allow specification of the pointers which may be associated with it. A pointer association is allowed if either pointer or the target identifies the possibility. (May wish to also allow some derived permissions: If P allowed to point to Q and Q allowed to point to R, then P allowed to point to R. If P allowed to point to R and Q allowed to point to R, then P allowed to point to Q or vice versa. However, P allowed to point to Q and P allowed to point to R is _not_ sufficient for Q to be allowed to point to R.) <ESTIMATED IMPACT> Textual modifications appear to be moderate in size, but widely distributed and hard to get right. A conforming processor could accommodate the declarations simply by treating names appearing in a POINTER attribute as though they were declared with the TARGET attribute, but using this information intelligently would be much harder. (Author's assessment: much too difficult to do in the context of F95.) <SUBMITTED BY> Kurt W. Hirchert, hirchert@ncsa.uiuc.edu <HISTORY> <EVENT> April 93: Initial proposal </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 061 <TITLE> Composable FORALL Functionality <KEYWORDS> FORALL, ARRAY, IMPLIED-DO, PARALLEL, EXPRESSION <STATUS> Registered <TARGET> <SUBGROUP> /parallel <VERSION> 1 <REQUIREMENT> Provide a mechanism for doing FORALL-like computations in an expression. <JUSTIFICATION> In many cases, this will allow a computation to be expressed more compactly and to avoid the need to explicitly declare arrays to be used as temporary storage. <SUGGESTED IMPLEMENTATION> The basic idea would be a slight modification of the implied DO that operates in parallel rather than serially and that can specify several index variables. In such a notation, "(A(J,I),I=1:N,J=1:M)" would denote the transpose of A(1:M,1:N). "(A(I,I),I=1:N)" would denote a diagonal. "(A(I)*B(J),I=1:N,J=1:M)" denotes an outer product of vectors A(1:N) and B(1:M). "(SUM(A(I,:)*B(:,J),I=1:N,J=1:M)" is an explicitly computed matrix multiply. "(A(I)%B(J),I=1:N,J=1:M)" is an expression of the mapping of an array of arrays to a multi-dimensional array in which the user controls which dimensions map where. With appropriate restrictions, this notation could appear on the right-hand side of a pointer assignment to recreate the skew section functionality of the Fortran 8x IDENTIFY statement. With some syntactic disambiguation (e.g., enclosure in _( )_ rather than just ( ) ), this notation could be useful on the left-hand side of ordinary assignment. <ESTIMATED IMPACT> Description could be largely self-contained, but it could be attractive to describe other notations in terms of this notation. Given that a conforming processor already has to support "RESHAPE((/((F(I,J),I=1,N),J=1,M) /),(/N,M/))", it should have no difficulty supporting "(F(I,J),I=1:N,J=1:M)". On MPP machines, it should be easier to generate good code (because the geometry of the loops is guaranteed to conform to the geometry of the array being generated). (Author's assessment: a portion of this could be done for F95, but the complete facility appears to be too much to do that quickly.) <SUBMITTED BY> Kurt W. Hirchert, hirchert@ncsa.uiuc.edu <HISTORY> <EVENT> April 93: Initial proposal </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 062 <TITLE> Composable WHERE Facility <KEYWORDS> WHERE, ARRAY, PARALLEL, EXPRESSION, MASK, NO VALUE <STATUS> Registered <TARGET> <SUBGROUP> /parallel <VERSION> 1 <REQUIREMENT> Provide a mechanism for performing WHERE-like selection of array positions to perform operations within expressions. <JUSTIFICATION> This facility would provide a significantly more concise notation in a wide range of cases where multiple statements are now required. <SUGGESTED IMPLEMENTATION> Implement the concept of "masked arrays". Like ordinary arrays, a masked array can store a value in each element, but a masked array offers the additional possibility that an element has no value. Ordinary operations produce a result of "no value" when invoked on an operation with no value. Assigning "no value" to an ordinary array element leaves that element unchanged. The intrinsics that currently take MASK arguments should also take masked arguments. The notation "mask->expression" evaluates the expression only at those positions where mask (has a value and) is true. It returns "no value" at the points where the mask is false (or has no value). [This uses the same evaluation rules as WHERE.] The notation "maskexpression+>expression" evaluates the expression only where the masked expression has no value. The result is the merger of the values from the two expressions. If exception handling is adopted, the notation "*>expression" is a masked expression that has no value for elements where exceptions were raised in their computation. In most contexts that currently take logical expressions, masked logical expressions may also be used, with no value being equivalent to .FALSE. Thus, "short circuit" evaluation of l1.AND.l2 and l1.OR.l2 may be expressed as l1->l2 and l1->.TRUE.+>l2 respectively. <ESTIMATED IMPACT> Huge. (Author's assessment: F95? no way!) <SUBMITTED BY> Kurt W. Hirchert, hirchert@ncsa.uiuc.edu <HISTORY> <EVENT> April 93: Initial proposal </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 063 <TITLE> Symmetric Linkage of Argument Attributes <KEYWORDS> DUMMY ARGUMENT, ACTUAL ARGUMENT, ATTRIBUTE <STATUS> Registered <TARGET> <SUBGROUP> /JOR <VERSION> 1 <REQUIREMENT> Provide a notation to symmetrically link argument attributes. <JUSTIFICATION> A symmetric link is easier to read and comprehend. The asymmetric approach of specifying the attribute of one argument by inquiring on the attribute of another breaks down when the arguments in question are optional. <SUGGESTED IMPLEMENTATION> Provide a means of declaring an "implied argument list". Implied arguments are not associated with actual arguments, but with the attributes of actual arguments. A single implied argument may be associated with more than one attribute, in which case the attributes are linked. <ESTIMATED IMPACT> Textual impact is contained. (For most purposes, implied arguments behave just like other INTENT(IN) dummy arguments and thus require no special handling.) Implementation is relatively straightforward. (In most cases, the compiler recreates the asymmetric implementation. When all the arguments with linked attributes are optional, the compiler must defer the selection of the basis for the asymmetric evaluation to run-time.) (Author's assessment: could be done in F95 context, but not likely to be.) <SUBMITTED BY> Kurt W. Hirchert, hirchert@ncsa.uiuc.edu <HISTORY> <EVENT> April 93: Initial proposal </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 064 <TITLE> Symbolic Names for Specification Expressions <KEYWORDS> SPECIFICATION, EXPRESSION, NAME, PARAMETER <STATUS> Registered <TARGET> <SUBGROUP> /JOR <VERSION> 1 <REQUIREMENT> Provide a mechanism for giving names to specification expressions. <JUSTIFICATION> Reduce verbosity. When the specification expression is constant, this can be done with a PARAMETER declaration. <SUGGESTED IMPLEMENTATION> Allow non-constant PARAMETER expressions. Expression is evaluated at beginning of instance of scoping unit and held constant for the rest of that instance (just like specification expressions). Result is then usable in specification expressions. <ESTIMATED IMPACT> Catching all the places that assume that PARAMETER implies constant. Otherwise, localized. Implementations already handle explicit specification expressions this way, so implementation is straightforward. (Author's assessment: could be done for F95, but probably won't be.) <SUBMITTED BY> Kurt W. Hirchert, hirchert@ncsa.uiuc.edu <HISTORY> <EVENT> April 93: Initial proposal </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 065 <TITLE> POINTER Objects as Operands <KEYWORDS> POINTER, DEFINED OPERATION, INTENT <STATUS> Registered <TARGET> <SUBGROUP> /OOF <VERSION> 1 <REQUIREMENT> Allow objects with the POINTER attribute to be used as operands in defined operations and generally as dummy arguments in functions and subroutines. The INTENT attribute should apply to the pointer, not the target. <JUSTIFICATION> Currently, the Fortran 90 standard does not allow dummy arguments with the POINTER attribute to have the INTENT attribute (5.1.2.3, [44:23-24]). However, operands in defined operations must be specified with INTENT(IN) (12.3.2.1.1, [169:18]). The combination of these two rules means that it is impossible to define operations for POINTER data objects. Discussion on this issue in the WG5 Corrigendum 2 ballot just completed indicated that it was not the intent of X3J3 to forbid the definition of operations on POINTER operands or to forbid the use of POINTER data objects as dummy arguments. Apparently, this situation was an oversight. This restriction should be fixed in Fortran 95. Users should have the freedom to use POINTER data objects as dummy arguments in procedures and to define operations for them. <ESTIMATED IMPACT> Since this proposal would provide a functionality that does not now exist, the direct impact would be minimal since the proposal would not invalidate existing codes. Providers of Fortran processors might have to do some extra work in order to ensure that allowing POINTER objects as operands and dummy arguments would not produce other types of conflicts. <REFLIST> <REF> ISO/IEC 1539:1993 (E) 5.1.2.3, 12.3.2.1.1 <REF> X3J3/94-160 Results of Corrigendum 2 Ballot <REF> X3J3/94-167 JOR Items on: Pointers as Operands, SYSTEM_CLOCK, and Array Dimensions </REFLIST> <SUBMITTED BY> Craig T. Dedo 17130 W. Burleigh Place Brookfield, WI 53005 Phone: 414-783-5869 Email: Craig.Dedo@mixcom.com </SUBMITTED BY> <HISTORY> <EVENT> May 94, meeting 129: Requirement drafted (94-167). </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 066 <TITLE> Generic COUNT_RATE Argument for SYSTEM_CLOCK <KEYWORDS> SYSTEM_CLOCK, DOUBLE PRECISION <STATUS> Registered <TARGET> <SUBGROUP> /JOR <VERSION> 1 <REQUIREMENT> The data type of the COUNT_RATE argument to the SYSTEM_CLOCK intrinsic subroutine should be changed from default INTEGER to generic REAL. <JUSTIFICATION> Currently the Fortran standard requires that all three arguments to SYSTEM_CLOCK be of type default INTEGER. While the INTEGER data type is acceptable for COUNT and COUNT_MAX, it causes serious accuracy problems for the COUNT_RATE argument. This is most likely an error in the existing standard which should be corrected. This error unnecessarily restricts the available precision. The processor clocks of many machines, most notably the clocks of MS-DOS PCs, have significant fractional components in their clock rates. On Intel (MS-DOS PC) machines, the clock ticks 18.2037 times per second. Requiring COUNT_RATE to be INTEGER causes considerable loss of accuracy for such machines. Interpretation 132 attempted to resolve this problem but it is at best a barely tolerable quick fix. As currently defined, interpretation 132 poses severe portability problems, even from one compiler to another on the same machine. In the Intel case, the interpretation allowed all three of these practices: 1. Increment COUNT by 1 every .05495 seconds but return a COUNT_RATE of 18. 2. Increment COUNT by 10 every .05495 seconds and return a COUNT_RATE of 182. 3. Increment COUNT by a variable amount every .05495 seconds and return a COUNT_RATE of 100. All three of these practices are, at best, counter-intuitive and not the behavior an ordinary programmer would expect. At worst, the are downright deceptive. Most programmers expect COUNT_RATE to be a very close approximation to the actual system clock rate. One of the most attractive features of Fortran is that it is generally intuitive and straightforward. There are relatively few traps and "gotchas" which cause problems for programmers who have less than expert level of ability. This characteristic is in sharp contrast to other languages, especially C and C++. In order to encourage the continued popularity of Fortran, X3J3 should eliminate such problems whenever possible. <ESTIMATED IMPACT> Minimal. Changing the data type to generic REAL would invalidate some existing code but changing the code should not require very much effort. <REFLIST> <REF> ISO/IEC 1539:1993 (E) 13.13.104 <REF> X3J3/94-006r1 Interpretation 000132 <REF> X3J3/94-160 </REFLIST> <SUBMITTED BY> Craig T. Dedo 17130 W. Burleigh Place Brookfield, WI 53005 Phone: 414-783-5869 Email: Craig.Dedo@mixcom.com </SUBMITTED BY> <HISTORY> <EVENT> May 94, meeting 129: Requirement drafted (94-167). </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 067 | <TITLE> Greater than 7 Array Dimensions <KEYWORDS> ARRAY, RANK | <STATUS> US TAG approved; ready for WG5 | <TARGET> 2000 revision <SUBGROUP> /JOR <VERSION> 1 <REQUIREMENT> The next Fortran standard should have a maximum limit on the number of | array dimensions of greater than 7. Processors should be able to support more than that maximum as an extension. <JUSTIFICATION> The original limit of seven dimensions in Fortran was established when Fortran was first published in 1957 and has never been changed since. The number of heavy duty applications which require more than seven dimensions is growing and becoming a significant proportion of high performance applications. Since Fortran does not now support more than seven dimensions, programmers of an application which requires more than seven dimensions usually write their application in another language. They do this even though in most cases they are more familiar with Fortran and would prefer to use Fortran. This concern was raised at the November 1993 X3J3 meeting and a member made a suggestion that someone should write a JOR item to address this issue. <ESTIMATED IMPACT> This requirement has no impact on existing code. <REFLIST> <REF> ISO/IEC 1539:1993 (E) 2.4.5, 6.2.2.2 </REFLIST> <SUBMITTED BY> Craig T. Dedo 17130 W. Burleigh Place Brookfield, WI 53005 Phone: 414-783-5869 Email: Craig.Dedo@mixcom.com </SUBMITTED BY> <HISTORY> | <EVENT> Aug 95, meeting 134: | Change max 255 to >7, approved by US TAG for F2000 as medium priority <EVENT> May 94, meeting 129: Requirement drafted (94-167). </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 068 <TITLE> Generic specification on the END INTERFACE statement <KEYWORDS> INTERFACE, GENERIC <STATUS> Registered <TARGET> <SUBGROUP> /JOR <VERSION> 1 <NOTE> Proposer's title: "Use of generic specification on the END INTERFACE statement" </NOTE> <REQUIREMENT> If an interface block is a generic interface then the generic specification that appears on the INTERFACE statement should optionally be allowed to appear on the END INTERFACE statement. <JUSTIFICATION> Most of the END statements in Fortran 90 can include an optional identifier. The END INTERFACE statement is one of the few END statements that can not have an identifier on it (the END WHERE statement is the only other case). By allowing the END INTERFACE statement of a generic interface to optionally indicate the generic specification, the language becomes more consistent. Allowing this feature can improve the visual impact of code. Consider the following code fragment: INTERFACE GEN FUNCTION F() END FUNCTION F FUNCTION S(I) END FUNCTION S END INTERFACE GEN If there were more numerous specific interfaces within the interface block then the appearance of GEN on the END INTERFACE reaffirms which generic interface is being defined. Many people already assume that it is part of the language. Repeatedly questions have been submitted to the X3J3 /interp subgroup that contain "END INTERFACE name" as part of the example. <SUGGESTED IMPLEMENTATION> The suggested implementation is given in terms of edits to the Fortran 90 standard. Replace R1203 with [167:18] R1203 <end-interface-stmt> is END INTERFACE [ <generic-spec> ] Add to the list of constraints after R1206 [167:36+] Constraint: The <generic-spec> may be included in the <end-interface-stmt> only if it was provided in the <interface-stmt> and, if included, must be identical to the <generic-spec> in the <interface-stmt>. In the first example of 12.3.2.1.1 change [169:31] END INTERFACE to END INTERFACE OPERATOR ( * ) </SUGGESTED IMPLEMENTATION> <COMPATIBILITY CONSIDERATIONS> No impact on existing code. <SUBMITTED BY> Janice C. Shepherd </SUBMITTED BY> <HISTORY> <EVENT> Jun 94: Proposal submitted via email. </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 069 <TITLE> Intrinsic function CONCAT <KEYWORDS> INTRINSIC FUNCTION CONCAT CONCATENATION ARRAY <STATUS> Registered <TARGET> <SUBGROUP> /JOR <VERSION> 1 <REQUIREMENT> Addition of an intrinsic function that concatenates the elements of an array. <JUSTIFICATION> In a two dimensional array, concatenation of the first dimension complemented with reshape provides the initial operation for a monolithic operation to join arrays but may be insufficient in general when concatenation is desired over the last dimension. For two dimensional array this can be achieved by transposing each array, concatenating over the first dimension then transposing but it is cumbersome and not obvious. Furthermore for consistency, all monolithic array operations should be generalized and defined over all dimensions supported by the language. <SUGGESTED IMPLEMENTATION> Define the intrinsic function CONCAT(A,B,DIM) where A and B are arrays and DIM is the dimension to concatenate over. DIM is optional and defaults to the first dimension. For example give the following fragment: A=RESHAPE((/ 0, 1, 2, 3 /),(/ 2, 2 /)) B=CONCAT(A,A) C=CONCAT(A,A,2) The result in B would be [ 0 1 ] [ 2 3 ] [ 0 1 ] [ 2 3 ] and C would be [ 0 1 0 1 ] [ 2 3 2 3 ] [Detailed edits available in /x3j3/JoR-references/mullin.ps at ftp.ncsa.uiuc.edu.] </SUGGESTED IMPLEMENTATION> <ESTIMATED IMPACT> This affects only new programs. It will not invalidate any existing programs. <SUBMITTED BY> Lenore R. Mullin, Scott Thibault, and Nicole Nemer Phone: 314-341-4492 Email: lenore@cs.umr.edu, sthib@cs.umr.edu, nnemer@cs.umr.edu </SUBMITTED BY> <HISTORY> <EVENT> Jul 94: Proposal submitted via email. </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 070 <TITLE> Extended indexing capabilities <KEYWORDS> INDEXING SECTIONS ARRAY EXPRESSION <STATUS> Registered <TARGET> <SUBGROUP> /parallel <VERSION> 1 <REQUIREMENT> The ability to index an array expression by subscripts or by sections. <JUSTIFICATION> Although a programmer can describe the desired indexing of an array expression over a number of lines, once monolithic arrays are added to the language it is more intuitive to describe what indices are desired after a number of operations are applied to one or more arrays in their entirety. <SUGGESTED IMPLEMENTATION> Extend grammar rule R701 to include the alternative "(" Expr ")" [ "(" section_subscript_list ")" ] For example some problems update only the interior of an array to keep the boundary constant as in G(2:N-1,2:N-1)=(u*G+(1-u)*G1)(2:N-1,2:N-1) which is a better way to write G(2:N-1,2:N-1)=u*G(2:N-1,2:N-1+(1-u)*G1(2:N-1,2:N-1) [Detailed edits available in /x3j3/JoR-references/mullin.ps at ftp.ncsa.uiuc.edu.] </SUGGESTED IMPLEMENTATION> <ESTIMATED IMPACT> This affects only new programs. It will not invalidate any existing programs. <SUBMITTED BY> Lenore R. Mullin, Scott Thibault, and Nicole Nemer Phone: 314-341-4492 Email: lenore@cs.umr.edu, sthib@cs.umr.edu, nnemer@cs.umr.edu </SUBMITTED BY> <HISTORY> <EVENT> Jul 94: Proposal submitted via email. </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 071 <TITLE> Linear array access <KEYWORDS> ARRAY ORDER LINEAR <STATUS> Registered <TARGET> <SUBGROUP> /OOF <VERSION> 1 <REQUIREMENT> The ability to access the linearly stored components of an array in memory. <JUSTIFICATION> Many languages access arrays in row major order. This would create a more ideal interface to language such as C where pointers could be used. <SUGGESTED IMPLEMENTATION> Since an array can be naturally thought of as a record it would be natural to access the linear stored components of an array as a record. As a record an array type would contain a dimension, size, and components field. The component field would be a vector. For example if A is a 2-D n-by-m array then A%component(2*n+2)=5 is equivalent to A(2,2)=5 [Detailed edits available in /x3j3/JoR-references/mullin.ps at ftp.ncsa.uiuc.edu.] </SUGGESTED IMPLEMENTATION> <ESTIMATED IMPACT> This affects only new programs. It will not invalidate any existing programs. <SUBMITTED BY> Lenore R. Mullin, Scott Thibault, and Nicole Nemer Phone: 314-341-4492 Email: lenore@cs.umr.edu, sthib@cs.umr.edu, nnemer@cs.umr.edu </SUBMITTED BY> <HISTORY> <EVENT> Jul 94: Proposal submitted via email. </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 072 <TITLE> Intrinsic function REVERSE <KEYWORDS> INTRINSIC FUNCTION REVERSE ARRAY <STATUS> Registered <TARGET> <SUBGROUP> /JOR <VERSION> 1 <REQUIREMENT> Addition of an intrinsic function that reverses the elements of an array. <JUSTIFICATION> Convolutions such as transpose and reverse are frequently used. The addition of monolithic arrays necessitates operation on monolithic arrays with the ability to define the axis of rotation for generality. <SUGGESTED IMPLEMENTATION> Define the intrinsic function REVERSE(A,DIM) where A is an array and DIM is the dimension to be reversed. DIM is optional and defaults to the first dimension. REVERSE would simply reverse the elements in a particular dimension. Convolution is one widely used operation that uses reverse. The convolution of two vectors could be written V*REVERSE(V) with the new intrinsic function. [Detailed edits available in /x3j3/JoR-references/mullin.ps at ftp.ncsa.uiuc.edu.] </SUGGESTED IMPLEMENTATION> <ESTIMATED IMPACT> This affects only new programs. It will not invalidate any existing programs. <SUBMITTED BY> Lenore R. Mullin, Scott Thibault, and Nicole Nemer Phone: 314-341-4492 Email: lenore@cs.umr.edu, sthib@cs.umr.edu, nnemer@cs.umr.edu </SUBMITTED BY> <HISTORY> <EVENT> Jul 94: Proposal submitted via email. </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 073 <TITLE> Multi-dimensional transpose <KEYWORDS> TRANSPOSE INTRINSIC FUNCTION ROW-MAJOR COLUMN-MAJOR ARRAY <STATUS> Registered <TARGET> <SUBGROUP> /JOR <VERSION> 1 <REQUIREMENT> Allow the transposition of array with a dimension greater than two. <JUSTIFICATION> Extensions are suggested for consistency and generality in the language. It may be desirable to transpose over an arbitrary dimension of an n-dimensional array. <SUGGESTED IMPLEMENTATION> The transpose of a n dimensional array is a rotation of the array about a particular axis. For n > 2 there is more than one rotation that can be performed. The particular rotation can be specified by a permutation vector of length n. The permutation vector describes how to permute the indices of the transposed array to access the original array. For example 2-D transpose would have the permutation vector (/ 2, 1 /) meaning the component (i,j) in the transposed matrix is the same as component (j,i) in the original matrix. The higher dimension transpose could use to provide compatibility. In order to interface other languages that do not use column-major ordering the components of array arguments must be reordered. This can be done with transpose. For example to convert the three dimensional array A to row-major order we could compute TRANSPOSE(A,(/ 3, 2, 1 /)). This permutation vector would be an extra argument to the transpose function and a default permutation could be chosen as a default value so that the argument is optional. TRANSPOSE(A,PERM) would transpose A with permutation vector PERM. PERM is optional and its default value is (/ d, (d-1), ... 1 /) where d is the dimension of A. TRANSPOSE(MATRIX) would still have the original semantics of 2-D transpose. [Detailed edits available in /x3j3/JoR-references/mullin.ps at ftp.ncsa.uiuc.edu.] </SUGGESTED IMPLEMENTATION> <ESTIMATED IMPACT> This affects only new programs. It will not invalidate any existing programs. <SUBMITTED BY> Lenore R. Mullin, Scott Thibault, and Nicole Nemer Phone: 314-341-4492 Email: lenore@cs.umr.edu, sthib@cs.umr.edu, nnemer@cs.umr.edu </SUBMITTED BY> <HISTORY> <EVENT> Jul 94: Proposal submitted via email. </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 074 <TITLE> Spaces should no longer be allowed in names <KEYWORDS> SPACE NAME FREE-FORM FIXED-FORM <STATUS> Registered <TARGET> <SUBGROUP> <VERSION> 1 <REQUIREMENT> That spaces in names no longer be permitted, and that a delimiter be required following a name. In other words, that the existing "feature" that blanks are ignored everywhere except in strings be deprecated ASAP, if not sooner. </REQUIREMENT> <JUSTIFICATION> 1. One of the most common errors is the omission of a comma or some other delimiter, or a misspelled keyword, that goes undetected. a. For example: INTEGERS A, B, C (misspelled keyword INTEGER goes undetected, and the variable A is undefined, but a new variable SA is defined.) b. For example: REAL I J, K (omitted comma, causes variable IJ to be defined, and variables I and J are of type INTEGER instead of type REAL). 2. Another frequent source of error is a misspelled variable name and a variable omitted from a declaration. 3. This requirement would go a long way to eliminating trivial sources of errors without (probably) affecting anybody. 4. If the matter became an issue, vendors could no doubt include an option to omit the check. However, it is unlikely that this would be necessary. </JUSTIFICATION> <SUBMITTED BY>Robin Vowels, email: Robin_Vowels@rmit.edu.au <HISTORY> <EVENT> 20 Sep 1994: submitted via email </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 075 <TITLE> Remove limitation on statement length <KEYWORDS> ARRAY PARAMETER FREE-FORM STATEMENT LENGTH | <STATUS> US TAG approved; ready for WG5 | <TARGET> 2000 revision <SUBGROUP> <VERSION> 1 <REQUIREMENT> Allow a user to specify large parameter arrays in a simple way: allow more characters in the statement. </REQUIREMENT> <JUSTIFICATION> Fortran-90 introduced the useful capability of defining parameter arrays in a single statement. E.g. real, parameter :: a(4) = (/ 1.0, 2.0, 3.0, 4.0 /) According to the f90 language specification, a statement should be less than 132 character on each line, and contain less than 40 continuation lines. This puts severe restrictions on the size of a parameter array. E.g. if the array x(n_dim) is declared as double precision each element may occupy e.g. 16 ascii characters, which means that you may type 8 elements (132/16=8.5) on each line and a total number of 40*8 = 320 elements in the entire statement. This means that n_dim MUST be less than 320. Sometimes it's useful to define larger parameter arrays. E.g. for multi- dimensional arrays containing gauss quadrature or chebyshev coefficients. </JUSTIFICATION> <SUGGESTED IMPLEMENTATION> This problem may be eliminated in case of the following modification of section 3.3.1.4 in ISO/IEC 1539:1991(E) : Remove the sentence: "A free form statement must not have more than 39 continuation lines." </SUGGESTED IMPLEMENTATION> <ESTIMATED IMPACT>Submitter says: Does not impact existing fortran codes, and the implementation cost should be negligible. </ESTIMATED IMPACT> <SUBMITTED BY> Jens Bloch Helmers Tel. work: (+47) 67 57 75 31 Det Norske Veritas Research AS Telefax: (+47) 67 57 75 20 N-1322 HOEVIK, NORWAY e-mail: helm@vr.dnv.no </SUBMITTED BY> <HISTORY> | <EVENT> Aug 95, meeting 134: | Approved by US TAG for F2000 as medium priority <EVENT> 22 Sep 1994: submitted via email </HISTORY> </FORTREQ> ---------------------------------------------------------------------- <FORTREQ> <NUMBER> 076 <TITLE> Need EXPM1 and LOGP1 intrinsics <KEYWORDS> EXP LOG INTRINSIC <STATUS> Registered <TARGET> <SUBGROUP> <VERSION> 1 <REQUIREMENT> The EXPM1 and the LOGP1 intrinsics are needed. </REQUIREMENT> <JUSTIFICATION> I am developing an algorithm that I wish to make available in standard Fortran. Unfortunately, as things stand now, I have to call two math intrinsic functions that are available in the C math library but aren't in Fortran. I understand that the Fortran standards committees are currently discussing numerical functionality in C that Fortran is missing. The two functions that I mentioned are fairly well established in the elementary functions community (see refs 1-3) and are quite fundamental and important. The two functions are: exp( x ) - 1, log( x + 1 ). When x is small, exp and log do not calculate these functions accurately. The two functions are inverse to one another and arise rather naturally (in Mathematica notation): Integrate[ Exp[ t ], {t, 0, x} ] == Exp[ x ] - 1. I think that these two functions should be considered for inclusion into Fortran. </JUSTIFICATION> <SUGGESTED IMPLEMENTATION> These functions are usually called expm1 and log1p. Their inclusion into Fortran would be a real benefit to those of us who use exp and log and need to calculate these functions accurately. </SUGGESTED IMPLEMENTATION> <REFLIST> <REF> Tang, P.T.P. "Table-driven implementation of the expm1 function in IEEE floating-point arithmetic." ACM TRANSACTIONS ON MATHEMATICAL SOFTWARE (June 1992) vol.18, no.2, p. 211-22. <REF> Tang, P.T.P. "Table-driven implementation of the logarithm function in IEEE floating-point arithmetic." ACM TRANSACTIONS ON MATHEMATICAL SOFTWARE (Dec. 1990) vol.16, no.4, p. 378-400. <REF> Tang, P.T.P. "Table-driven implementation of the exponential function in IEEE floating-point arithmetic." ACM TRANSACTIONS ON MATHEMATICAL SOFTWARE (June 1989) vol.15, no.2, p. 144-57. </REFLIST> <SUBMITTED BY> William Behrman Scientific Computing and Computational Mathematics Stanford University email: behrman@sccm.Stanford.EDU </SUBMITTED BY> <HISTORY> <EVENT> 14 Mar 1995: submitted by email </HISTORY> </FORTREQ> ---------------------------------------------------------------------- | <FORTREQ> | <NUMBER> 077 | <TITLE> Annex of processor dependent items | <KEYWORDS> | <STATUS> US TAG approved; ready for WG5 | <TARGET> 2000 revision | <SUBGROUP> | <VERSION> 1 | | <REQUIREMENT> | Include in the standard an annex that lists all the language features | that have processor dependent aspects. Specifically all the language features | where the standard indicates the results/values are processor dependent. This | annex is not intended to include language features where there is an | implied processor dependent nature (such as the result of arithmetic | operations). | </REQUIREMENT> | | <JUSTIFICATION> | The list of language features where the standard indicates that there | are processor dependent aspects appears to be growing with each new | release of the standard. It would be helpful for implementers and users | if a list in an annex detailed all the language features where some | aspect of the semantics needs to be specified by the processor. The | benefit for implementers is they get a check list against which to verify | that their documentation includes definitions of processor dependent | aspects. The benefit for users is they are alerted some areas of the | language where they may encounter differences between processors. | | Once the annex is established further ideas for making use of the information | might include (note these are not part of this requirement just ideas): | - adding examples to the annex to show ways to write "portable" code with | respect to the various items | | - require a processor to list in their documentation specifics for | processor dependent behaviour for the items in the annex. | </JUSTIFICATION> | | <SUGGESTED IMPLEMENTATION> | </SUGGESTED IMPLEMENTATION> | | <ESTIMATED IMPACT>Submitter says: | No negative impact. | </ESTIMATED IMPACT> | | <SUBMITTED BY> | Janice C. Shepherd X3J3/95- | </SUBMITTED BY> | | <HISTORY> | <EVENT> Aug 95, meeting 134: | Submitted, approved by US TAG for F2000 as high priority | </HISTORY> | | </FORTREQ> | ------------------------------------------------------------------------------- | <FORTREQ> | <NUMBER> 078 | <TITLE> Standardized handling of modules <KEYWORDS> <STATUS> | <KEYWORDS> | <STATUS> Registered | <TARGET> | <SUBGROUP> | <VERSION> 1 | | <REQUIREMENT> | Copious postings from confused users suggest that standardizing how modules | are | processed would be helpful to users wishing to move their code from Fortran | processor to Fortran processor. | </REQUIREMENT> | | <JUSTIFICATION> | Not having this specified makes it virtually impossible to write reusable | makefiles, greatly increasing the ongoing cost of multi-platform development | using Fortran. To the extent that users choose a language based on life-cycle | costs, this makes Fortran a less appealing language. | </JUSTIFICATION> | | <SUGGESTED IMPLEMENTATION> | </SUGGESTED IMPLEMENTATION> | | <ESTIMATED IMPACT> | Doing work on this, or any other feature, means we won't be | working on something else. It is hard to quantify the precise impact at this | time. It should be noted that this would require us to specify a lot of things | currently outside the scope of Fortran (such as "file scope" and the like). | </ESTIMATED IMPACT> | | <SUBMITTED BY> | Keith H. Bierman | </SUBMITTED BY> | | <HISTORY> | <EVENT> Aug 95, meeting 134: | Submitted. | </HISTORY> | | </FORTREQ> | ------------------------------------------------------------------------------- | <FORTREQ> | <NUMBER> 079 | <TITLE> Asynchronous I/O | <KEYWORDS> | <STATUS> Registered | <TARGET> | <SUBGROUP> | <VERSION> 1 | <NOTE> See also pFR #080 | | <REQUIREMENT> | The next Fortran standard should provide the capability to start READ and | WRITE operations and then continue executing other parts of the program | without waiting for the READ or WRITE operation to complete (commonly called | asynchronous I/O). This would allow the simultaneous execution of I/O | operations and other computational processes. If file sharing is also | available on the processor, a program could simultaneously execute READ and | WRITE operations on the same file. | | The feature should be able to have several I/O operations on the same unit | pending at the same time. | | The feature should support auxiliary operations. This would include | specifying asynchronous I/O when opening the file, investigating whether an | asynchronous I/O operation has completed, and waiting for the completion of an | asynchronous I/O operation. | | This feature should work in the same way whether the form is FORMATTED or | UNFORMATTED and whether the access method is SEQUENTIAL or DIRECT. | </REQUIREMENT> | | <JUSTIFICATION> | This feature would give the programmer the capability to avoid lengthy | waits for the completion of I/O operations. This would speed up the execution | of large I/O bound programs by a factor of 2 or more. In most such cases, the | programmer knows how to access the data most efficiently, so the speed gains | can be substantial. This would result in better utilization of computer | resources, better turnaround times in subsequent runs, and more efficient use | of programmer time. | | Additional benefits include: | | <LIST> | <ITEM> Programmers can avoid disk thrashing, since they can make more | effective use of virtual memory capabilities. | <ITEM> Heavy duty numeric computation in science and engineering can | certainly benefit by the efficiencies that this feature would make | available. | <ITEM> Most likely, heavy duty programs in data base and business | applications would also benefit. | <ITEM> Any application which knows the pattern of I/O occurrences could | benefit. | </LIST> | | Since such capabilities have been offered in many different Fortran | compilers over the past 30 years, there is obvious utility for such a feature. | | Some vendors of Fortran language products provide this capability. | However, since there is no standard, there are different and incompatible | implementations from different vendors. | </JUSTIFICATION> | | <SUGGESTED IMPLEMENTATION>Submitter says: | An effective implementation must provide several capabilities. These | include: | | <ITEM> Asynchronous READ and WRITE operations; | <ITEM> Selection of either synchronous or asynchronous I/O when opening a | file on a unit; | <ITEM> Inquiry of whether an asynchronous I/O operation has completed; | and | <ITEM> Waiting for the asynchronous I/O operation to complete in cases | where the other execution has completed before the asynchronous I/O | has completed. | | An effective way to implement this feature would be by extending the I/O | statements which are already available. Following is a brief overview of the | necessary keywords which are required in order to implement this capability. | | OPEN (ACCESS = access-spec, "ASYNCHRONOUS") | | In order to specify the use of asynchronous I/O, the ACCESS keyword in the | OPEN statement would need to be extended to allow a second specification in | the character expression which follows the keyword. This second specification | would have the values of either "SYNCHRONOUS" or "ASYNCHRONOUS" and would | specify synchronous or asynchronous I/O, respectively. | | INQUIRE (unit, ASYNCHRONOUS_COMPLETION=scalar-logical-var) | INQUIRE (file, ASYNCHRONOUS_COMPLETION=scalar-logical-var) | | These statements would allow the programmer to inquire whether the | referenced file or I/O unit has completed the previously started asynchronous | I/O operation. | | INQUIRE (unit, ASYNCHRONOUS=scalar-char-variable) | INQUIRE (file, ASYNCHRONOUS=scalar-char-variable) | | These statements would allow the programmer to inquire whether asynchronous | I/O is allowed on the referenced file or I/O unit. The scalar-char-variable | would be assigned the value YES if asynchronous I/O is allowed on the file or | I/O unit, NO if asynchronous I/O is not allowed on the file or I/O unit, and | UNKNOWN if the procesor is unable to determine whether or not asynchronous I/O | is allowe on the file or I/O unit. | | SYNCHRONIZE_IO (unit) | | This statement would suspend execution of the executable part of the | program until the asynchronous I/O operation has completed. | | There would be no need for extra syntax for asynchronous READ or WRITE | operations; the existing READ and WRITE statements would be sufficient. | </SUGGESTED IMPLEMENTATION> | | <ESTIMATED IMPACT> | It is difficult to estimate the difficulty of implementation. Since prior | experience exists with non-standard implementations of this feature, | implementors could build on this prior experience. | | There may be possible complications in parallel operations. The feature | would have to be carefully defined so as to minimize the impact on parallel | operations. It is not expected to [...?Ed] | </ESTIMATED IMPACT> | | <REFERENCE> | ISO/IEC 1539:1991 (E) 9.2.1.2, 9.3.4.3, 9.4.1, 9.6.1 | </REFERENCE> | | <SUBMITTED BY> | Craig Dedo Tony Warnock | Elmbrook Computer Services Los Alamos National Laboratory | 17130 W. Burleigh Place P. O. Box 1663, MS B265 | Brookfield, WI 53005 Los Alamos, NM 87544 | (414) 783-5869 (505) 667-2225 | Email: Craig.Dedo@mixcom.com Email: ttw@lanl.gov | </SUBMITTED BY> | | <HISTORY> | <EVENT> Aug 95, meeting 134: | Submitted. | </HISTORY> | | </FORTREQ> | ------------------------------------------------------------------------------- | <FORTREQ> | <NUMBER> 080 | <TITLE> Asynchronous I/O (proposed HPFF work) | <KEYWORDS> | <STATUS> US TAG approved; ready for WG5 | <TARGET> 2000 revision | <SUBGROUP> | <VERSION> 1 | <NOTE>See also pFR #079 | | <REQUIREMENT> | Permit application control of overlapping computation and I/O. Formatted and | unformatted I/O are required. | | The direction taken by HPF (which has been considering this facility) is | similar to the old IBM VS FORTRAN implementation. If practical, this facility | should be harmonized with HPF work in this area. | | It is envisioned that READ and WRITE statements will be augmented to allow | control of asynch I/O (if it should occur, and a variable to contain the | status | of that particular I/O command). In addition a WAIT statement to allow the | program to wait for the transaction to complete. It may be necessary or useful | to augment the OPEN statement to limit asynch I/O to files that have been | opened with for asynch I/O. It should be possible to test if an I/O | transaction | is completed without waiting. | | Ideally such a facility would handle multiple outstanding (pending) I/O | transactions. | </REQUIREMENT> | | <JUSTIFICATION> | Advances in CPU performance continue to outstrip advances in input/output | device performance. This is further aggravated by the increasing volume of | multiprocessor computer systems. | | Many systems of the late sixties had such facilities (notably the IBM | extensions and the CDC BUFFERIN/OUT) supercomputer users have found such | facilities invaluable, and it is viewed as important enough in that community | to have spawned an HPF subgroup dedicated to defining such a facility. | | Many previous implementations were restricted to unformatted I/O. This has | never been user friendly, and the ability to offload the computational burden | of data conversion is helpful in a variety of applications and in many | systems. | There has been some implementation experience with offloading format | processing | (a Fujitsu vector machine front-ended by an IBM S/370 compatible comes to | mind, | as well as some array processor systems). | | It can be argued that if users had a sufficiently powerful task/control | parallelism facility that a special I/O facility would not be needed. However, | experience in C/POSIX applications suggests that an approach of that sort | places an undue burden on the application developer. | </JUSTIFICATION> | | <SUGGESTED IMPLEMENTATION> | As a first approximation, we should include the HPF text from their last | meeting. Note that they are continuing to evolve their proposal. FWIW from | memory: | | OPEN(...,synch='synch|asynch') | READ(unit=,fmt=,astat=ivar,...) | WRITE(unit=...,astat=ivar,...) | WAIT (ivar) ! wait until done | STATUS(ivar,iostat=) ! test if done, no wait | | </SUGGESTED IMPLEMENTATION> | | <ESTIMATED IMPACT>Submitter says: | Doing work on this, or any other feature, means we won't be | working on something else. It is hard to quantify the precise impact at this | time. | | It would be necessary to be careful in defining how this interacts with | ENABLE. | It might be helpful to have loop-local PRIVATE variables. There are probably a | number of other interactions not obvious at this time. | </ESTIMATED IMPACT> | | <SUBMITTED BY> | Keith H. Bierman | </SUBMITTED BY> | | <HISTORY> | <EVENT> Aug 95, meeting 134: | Submitted, approved by US TAG for F2000 as high priority | </HISTORY> | | </FORTREQ> | ------------------------------------------------------------------------------- | <FORTREQ> | <NUMBER> 081 | <TITLE> PRIVATE and SHARED variables for TASK parallelism | <KEYWORDS> | <STATUS> US TAG approved; ready for WG5 | <TARGET> 2000 revision | <SUBGROUP> | <VERSION> 1 | | <REQUIREMENT> | Parallel processing on (sometimes virtual) shared memory machines has become | fairly widespread. On such machines, it is often the case that there are | multiple "threads" of control (often called TASKS in Fortran contexts, and | threads in POSIX contexts). On such systems one may have something like: | | DO i = 1, n ! do this in parallel | call FRED(x,y,z) | END DO | | It is then often necessary for FRED to have "private" copies of some or all of | the variables for its internal processing. | | The same need can come about using the FORALL construct on such systems. | Currently there are constraints intended to disallow writing such programs. | | A complete solution would include some syntax to allow the user to specify | where control parallelism can occur, allow users to specify which variables | are | to be shared and which are to be private, and relax any constraints present to | facilitate the use of procedure calls in FORALL. An ideal solution might also | include a facility to declare loop local variables, that would permit | programmers to write small procedures inline, rather than artificially | requiring a procedure call. | | It should be noted that these facilities could be provided separately, that is | adding PRIVATE and SHARED could be done whether or not a new syntax for | task-level parallelism is provided, and loop local variables (ala ALGOL | derived | languages) could be provided independent of either of the two other | facilities. | But an ideal solution would integrate them all cleanly. | | Note that if the current ENABLE proposal were to be added to the language, | some | solution for PURE procedures in FORALL constructs with exceptions enabled will | probably be required (or the ENABLE construct will be of limited value, or | another approach will have to be found). | </REQUIREMENT> | | <JUSTIFICATION> | Parallel computers are no longer the exclusive province of the very rich, 4 | processor desktop workstations are available for a few tens of thousands of | dollars (and dropping), and some published statistics suggest that there are | already tens of thousands of MP capable systems have already been deployed | (8/95). | | In addition, there are many vendors with a variety of extensions to their | existing Fortran processors to work on such systems. | | Lastly, it should be noted that there is a POSIX standard (4a) which defines a | threading facility for the C programming language. | </JUSTIFICATION> | | <SUGGESTED IMPLEMENTATION> | </SUGGESTED IMPLEMENTATION> | | <ESTIMATED IMPACT> Submitter says: | Doing work on this, or any other feature, means we won't be | working on something else. It is hard to quantify the precise impact at this | time. It should be noted that this was once the province of X3H5 but they were | unable to complete their work. It is arguably hard, and the state-of-the-art | in | hardware, OS support, and automatic compiler directed parallelization is | quickly changing. | | A complete solution, including loop-scope variables would change the language | in substantial and fundamental ways. It will be a lot of work. | </ESTIMATED IMPACT> | | <SUBMITTED BY> | Keith H. Bierman | </SUBMITTED BY> | | <HISTORY> | <EVENT> Aug 95, meeting 134: | Submitted, approved by US TAG for F2000 as medium priority | </HISTORY> | | </FORTREQ> | ------------------------------------------------------------------------------- | <FORTREQ> | <NUMBER> 082 | <TITLE> Interval arithmetic support | <KEYWORDS> | <STATUS> Registered | <TARGET> | <SUBGROUP> | <VERSION> 1 | | <REQUIREMENT> | Provide datatypes and intrinsic operators for interval arithmetic. | | Interval arithmetic provides a way for users to have confidence in the quality | of their computations, facilitates the solution of entire classes of | numerically difficult problems, and simplifies the algorithm choice. | </REQUIREMENT> | | <JUSTIFICATION> | It is not possible for user coded implementations to achieve performance | levels | that can be obtained if the compilation system is intimately aware of the | interval arithmetic. | | As more and more complex decisions are made on the basis of computer | simulation, | the need to quantify the precision and accuracy of computations increases, as | well as the cost of being wrong. | </JUSTIFICATION> | | <SUGGESTED IMPLEMENTATION> | Some text may be provided later. There is some experience in (alas no longer | supported) CDC FORTRAN compiler(s). In addition a dialect of Pascal from the | University of Karlshule. | | In principle, it should be possible to define a standard module which | defines a | new family of REAL datatypes and operators. It is not currently possible for | users to extend I/O to new types; it would be highly desirable to extend the | I/O system to handle these INTERVAL REAL types and their special needs. | </SUGGESTED IMPLEMENTATION> | | <ESTIMATED IMPACT> Submitter says: | Doing work on this, or any other feature, means we won't be | working on something else. It is hard to quantify the precise impact at this | time. Aside from considerable work at the standard writing level, | implementation is fairly complicated (especially if one is serious about | getting good performance on many existing hardware designs). | </ESTIMATED IMPACT> | | <SUBMITTED BY> | William Walster (via the keyboard of Keith Bierman) | </SUBMITTED BY> | | <HISTORY> | <EVENT> Aug 95, meeting 134: | Submitted. | </HISTORY> | | </FORTREQ> -------------------------------------------------------------------------------