####################################################################### # # # X3J3/93-004r4s # # Journal Of Requirements/Subset # # # # Oct 1993 # # # ####################################################################### | NB: This is a subset of the full Journal of Reuirements (JOR). Only | minimal entries have been retained for requirements with a status | of "Archival". The complete JOR is X3J3/93-004r5. Status Number Title A 000001 Bit Data Type, Non-string R 000002 Variant Derived Type R 000003 Array Components of Array Structures Xa 000004 FORALL A 000005 DIAGONAL Function A 000006 PROJECT Function A 000007 REPLICATE Function A 000008 RANK Intrinsic Function A 000009 FIRSTLOC and LASTLOC intrinsics R 000010 Nesting of Internal Procedures A 000011 Internal Procedure Names as Actual Arguments Xb 000012 Condition Handling R 000013 Pointer Initialization C 000014 Language Management Xa 000015 Conditional Compilation Xa 000016 Command Line Arguments and Environmental Variables Xb 000017 Bit Data Type, String Xb 000018 Controlling Pointer Bounds R 000019 Variant Derived Type, Untagged R 000020 User Defined Elemental Functions R 000021 Obsolesce Fixed Source Form R 000022 Keep It Simple, Make It Fine R 000023 User Defined Intrinsic Functions R 000024 Nested WHERE Statements R 000025 Pure User Functions and Subroutines R 000026 Directives R 000027 Packaging Implementer Specific Intrinsics in MODULEs R 000028 Binding to IEEE 754 R 000029 Interline Optimization R 000030 Variable Rank Arrays R 000031 Efficient Varying Length Character Type R 000032 POSIX Binding to Fortran 90 R 000033 Object Oriented Fortran, OOF R 000034 Variable Repeat Specifiers in Formats R 000035 Specifying Default Precisions | R 000036 MAXLOC and MINLOC To Accept CHARACTER Arguments INTRODUCTION This document is an internal working document of X3J3, the Fortran Technical Committee of the American National Standards Association, and contains proposed requirements for future revisions of the Fortran standard. This is an evolving document, and it is expected that more requirements will be added. The status of each item in this document is tracked with the STATUS field, the values of which are: R. Registered Received and assigned a number by the requirements editor, and incorporated into the next revision of this standing document. C. X3J3 consideration in progress Put on the table for active consideration by X3J3; requires a majority vote of the committee. Xa. X3J3 approved; ready for WG5 (1995 revision) Xb. X3J3 approved; ready for WG5 (2000 revision) Submitted to WG5, with the indicated recommendation for the | target revision cycle, by a majority vote of X3J3. S. Satisfied Substantially satisfied in a new revision of the Fortran, or a related, standard, as determined by a two-thirds vote of X3J3. | F. Failed WG5 approval Failed to gain approval by WG5 after forwarding from X3J3. This status is equivalent to "X3J3 consideration in progress". A. Archival Withdrawn from active consideration by X3J3; requires a two-thirds vote of the committee. ####################################################################### 001 Bit Data Type, Non-string <KEYWORDS> BIT, INTRINSIC, DATA TYPE <STATUS> Archival <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. </FORTREQ> ----------------------------------------------------------------------- <FORTREQ> <NUMBER> 002 <TITLE> Variant Derived Type <KEYWORDS> DERIVED TYPE, VARIANT, TAG <STATUS> Registered <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 <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> X3J3 approved; ready for WG5 (1995 revision) <VERSION> 1 <NOTE> Grandfather requirement from old Appendix F <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> [To be supplied. Requirement "grandfathered".] <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> HPF <REF> Section F.2.3 of S8.104 Appendix F (aka X3J3/119-LJM-1) </REFLIST> <SUBMITTED BY> X3J3 <HISTORY> | <EVENT> Jul 93, WG5 meeting: | 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 <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. </FORTREQ> ----------------------------------------------------------------------- <FORTREQ> <NUMBER> 006 <TITLE> PROJECT Function <KEYWORDS> PROJECT, FUNCTION, ARRAY, MASK, FIELD, REDUCE RANK <STATUS> Archival <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. </FORTREQ> ----------------------------------------------------------------------- <FORTREQ> <NUMBER> 007 <TITLE> REPLICATE Function <KEYWORDS> REPLICATE, FUNCTION, ARRAY <STATUS> Archival <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. </FORTREQ> ----------------------------------------------------------------------- <FORTREQ> <NUMBER> 008 <TITLE> RANK Intrinsic Function <KEYWORDS> RANK, INTRINSIC, INQUIRY FUNCTION <STATUS> Archival <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. </FORTREQ> ----------------------------------------------------------------------- <FORTREQ> <NUMBER> 009 <TITLE> FIRSTLOC and LASTLOC intrinsics <KEYWORDS> FIRSTLOC, LASTLOC, INTRINSIC <STATUS> Archival <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. </FORTREQ> ----------------------------------------------------------------------- <FORTREQ> <NUMBER> 010 <TITLE> Nesting of Internal Procedures <KEYWORDS> INTERNAL PROCEDURES, NESTING <STATUS> Registered <VERSION> 1 <NOTE> Grandfather requirement from old Appendix F <REQUIREMENT> An internal procedure may host other internal procedures. <JUSTIFICATION> [To be supplied if the STATUS is changed from "Registered" to "X3J3 consideration in progress". Requirement "grandfathered".] <COMPATIBILITY CONSIDERATIONS> This will not directly affect existing code. <REFLIST> <REF> Section F.3.1 of S8.104 Appendix F (aka X3J3/119-LJM-1) </REFLIST> <SUBMITTED BY> X3J3 <HISTORY> <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 <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. </FORTREQ> ----------------------------------------------------------------------- <FORTREQ> <NUMBER> 012 <TITLE> Condition Handling <KEYWORDS> CONDITION, ENABLE, SIGNAL, HANDLER, EXCEPTION <STATUS> X3J3 approved; ready for WG5 (2000 revision) <VERSION> 1 <NOTE> Grandfather requirement from old Appendix F <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> [To be supplied if the STATUS is changed from "Registered" to "X3J3 consideration in progress". Requirement "grandfathered".] <SUGGESTED IMPLEMENTATION> See section of S8.104 Appendix F. <REFLIST> <REF> Section F.4.1 of S8.104 Appendix F (aka X3J3/119-LJM-1) </REFLIST> <SUBMITTED BY> X3J3 <HISTORY> | <EVENT> Jul 93, WG5 meeting: | Investigation for 1995 revision requested (B9 Resolution, item C5) <EVENT> May 93, meeting 125: Status changed to approved/2000 (20-2). <EVENT> Apr 93: Section F.4.1 of S8.104 Appendix F material reformatted by L. Moss. <EVENT> Feb 93, meeting 124: X3J3/S17 (JOD), less vector-valued subscripts and significant blanks, becomes X3J3/93-004, Journal Of Requirements as part of chair's reorganization of X3J3 (see 92-181). <EVENT> Nov 87, Meeting 106: Conversion of S8.104 Appendix F to X3J3/S17, Journal Of Development, approved by X3J3 (18-12). </HISTORY> </FORTREQ> ----------------------------------------------------------------------- <FORTREQ> <NUMBER> 013 <TITLE> Pointer Initialization <KEYWORDS> POINTER, INITIALIZATION, DISASSOCIATED, UNDEFINED <STATUS> Registered <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 ISO/IEC JTC1/SC22/WG5-N871. </REFLIST> <SUBMITTED BY> X3J3/JOR subgroup for DIN Fortran Working Group <HISTORY> | <EVENT> Jul 93, WG5 meeting: | 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> X3J3 consideration in progress <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 ISO/IEC JTC1/SC22/WG5-N871. <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> Jul 93, WG5 meeting: | Recommended for 1995 revision (resolution B9, item B4.2) Straw vote to change status to approved/archival/undecided: 9-3-8; no change. <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> X3J3 approved; ready for WG5 (1995 revision) <VERSION> 1 <REQUIREMENT> Permit the conditional inclusion of Fortran statements (declarations, executable constructs, comment lines, procedures, etc.) in programs. The conditions are based on the values of compile-time variables. <JUSTIFICATION> This would permit users to maintain only one version of a source for use on various systems or under various conditions. The C language has such facilities and users have found them invaluable. <COMPATIBILITY CONSIDERATIONS> No impact on existing programs. Would add slightly to the burden of implementers. <REFLIST> <REF> Item 6 of ISO/IEC JTC1/SC22/WG5-N871. <REF> ISO/IEC JTC1/SC22/WG5-N899. <REF> ISO/IEC JTC1/SC22/WG5-N539. </REFLIST> <SUBMITTED BY> X3J3/JOR subgroup for HPFF <HISTORY> <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> X3J3 approved; ready for WG5 (1995 revision) <VERSION> 2 <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> 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> 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> X3J3 approved; ready for WG5 (2000 revision) <VERSION> 2 <REQUIREMENT> Add BIT data type using the syntax and semantics of CHARACTER type, i.e., declaration syntax would be identical to CHARACTER except for the word BIT. BIT initialization, substring operation, concatenation, and input/output would also parallel CHARACTER. Add the attribute UNSIGNED. The attribute's interpretation is discussed further below. Operators: Concatenation (//), the INTEGER arithmetic operators (+, -, *, /, **, .NE., .LT., ...) and the LOGICAL operators (.NOT., .AND., .OR., .EQV., and .NEQV.) which are Boolean when they are used with BIT operands. LOGICAL and BIT operands may not be mixed, i.e., a BIT datum is not .TRUE. or .FALSE.. In addition, consider extending the LOGICAL operators to include all 16 binary operators. It is not necessary for WG5/X3J3 to anticipate how BIT data type will be used, rather, the above requirements would extend all "reasonable" combinations of possibilities to BIT data and operations. The UNSIGNED attribute determines how BIT operands are aligned when the appear as an operand. Signed BIT (the default) is sign extended and truncated similarly, e.g., b(5:7) = B'1111101' has the value 101 stored into the three bits -- user beware. For UNSIGNED, zeros filled on the left. The shift functions from the Mil Standard are also available. The possibility of another attribute LEFT JUSTIFY (the default is RIGHT JUSTIFY) needs to be examined. In an array of BIT strings, the bits of consecutive array elements are contiguous. That is, for BIT*11 A(27) the first bit of A(2) immediately follows the last bit of A(1). BIT variables cannot be EQUIVALENCEd with variables of other types, the same as CHARACTER. But the committee should consider BIT and CHARACTER EQUIVALENCE. BIT variables can be placed in SEQUENCE derived types. This feature has to be examined carefully. Some examples: BIT, UNSIGNED :: bu_1*1, bu_2*2, ... BIT :: b_1*1, b_2*2, ... ... b_2 = b_2(2:) + bu_1 b_4 = b_1 // b_2 // B'1' IF ( 2 * bu_1 + 1 > ... bu_2 = 2*( b_1 .AND. bu_1 ) But not: IF ( bu_1 ) GO TO 10 Since the variables are Boolean, not LOGICAL. Review Appendix F from earlier drafts of the Fortran Standard. <JUSTIFICATION> Artificial life, genetic algorithms, and cellular automata are exciting, new (the programming community is becoming aware of them) developments. Programming in these fields would be facilitated by the BIT data type. DOD utilizes (requires?) BIT data type. Users have been requesting BIT for years. There are implementations that should be standardized and Fortran 90 features that could be deprecated. Most compilers could generate more efficient code if BIT were an intrinsic type. <SUGGESTED IMPLEMENTATION> To be accomplished after WG5 authorization. <REFLIST> <REF> 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> 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> X3J3 approved; ready for WG5 (2000 revision) <VERSION> 1 <REQUIREMENT> Allow a user to specify the bounds of a pointer that is associated with a target by the pointer assignment statement. <JUSTIFICATION> Currently a pointer that is associated with a target by the pointer assignment statement has the bounds of the target unless the target is an array section or an array expression, in which case the lower bound is one and the upper bound is the extent. The user has no control over setting the bounds. This is inconsistent with the passing of an actual argument array, array section, or array expression to a dummy argument. The lower bound of a dummy argument may be specified in a declaration statement. A user should have a similar amount of control over the bounds of array pointers. <COMPATIBILITY CONSIDERATIONS> This affects only the pointer facility. It will not invalidate any existing programs. <REFLIST> <REF> Item 2 of ISO/IEC JTC1/SC22/WG5-N871. <REF> ISO/IEC JTC1/SC22/WG5-N780. </REFLIST> <SUBMITTED BY> Jeanne Martin Email: jtm@llnl.gov </SUBMITTED BY> <HISTORY> <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 <VERSION> 1 <NOTE> Counter proposal to Item 2 of 93-004r <REQUIREMENT> Extend derived types to permit a single optional variant part. A variant part should specify alternative sequences of components. Any or all of these sequences would have an interpretations at any given time in a structure of that type. It is the responsibility of the user to use a sequence which does have a valid interpretation. <JUSTIFICATION> Users of other languages find the ability to pack data in a data structure (such as a derived type) very useful for reducing memory requirements. Indeed, Fortran itself has always supported EQUIVALENCE for the overlaying of data to save memory. Users of DEC's UNION and MAP extension to FORTRAN 77 are looking for a similar facility in a standard Fortran. <SUGGESTED IMPLEMENTATION> Add an EQUIVALENCE construct to derived types, in which components which are to be overlayed in memory must be within an EQUIVALENCE/END EQUIVALENCE construct. For Example: type example integer a ! non overlayed equivalence integer b ! overlayed with c integer c ! overlayed with b end equivalence integer d ! non overlayed end type type(example) x x%b = 2 x%a = x%c ! x%a gets the value 2 The current EQUIVALENCE rules would be used inside the derived type, as they are outside of the derived type. The storage requirements for the equivalence construct would be the same as the largest component inside the equivalence construct. Groups of elements to be equivalenced can be put inside a derived type (outside of the derived type defining the EQUIVALENCE construct), and then included within the EQUIVALENCE construct. <COMPATIBILITY CONSIDERATIONS> No impact on existing code. <REFLIST> <REF> Item 2 of X3J3/93-004r <REF> X3J3/93-164 </REFLIST> <SUBMITTED BY> Greg Lindhorst, gregli@microsoft.com, 206-936-2169 <HISTORY> <EVENT> May 93, Meeting 125: Submitted as X3J3/93-164 </HISTORY> </FORTREQ> ----------------------------------------------------------------------- <FORTREQ> <NUMBER> 020 <TITLE> User Defined Elemental Functions <KEYWORDS> ELEMENTAL, FUNCTION <STATUS> Registered <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/93-163 </REFLIST> <SUBMITTED BY> Greg Lindhorst, gregli@microsoft.com, 206-936-2169 <HISTORY> <EVENT> May 93, Meeting 125: Submitted as X3J3/93-163 </HISTORY> </FORTREQ> ----------------------------------------------------------------------- <FORTREQ> <NUMBER> 021 <TITLE> Obsolesce Fixed Source Form <KEYWORDS> SOURCE FORM, OBSOLESCENT <STATUS> Registered <VERSION> 1 <REQUIREMENT> Add fixed source form to the list of obsolescent features. <JUSTIFICATION> The need for language evolution by eventually removing some features has often been noted. Fixed source form is an artifact of the days of punched cards. It was retained in f90 for compatibility with old code. The blank insignificance of fixed source form places awkward requirements on the syntax. Some future syntax additions might therefore be less awkward if fixed source form were eliminated. Categorizing fixed source form as obsolete would facilitate its deletion from future standards. <SUGGESTED IMPLEMENTATION> Nothing required now. If fixed source form were deleted from a subsequent standard, I would expect to see utilities to convert old fixed source form code to free form, but vendors would not be required to provide such a utility. Some such utilities already exist. Vendors could choose to continue support of fixed source form as an extension. <COMPATIBILITY CONSIDERATIONS> No immediate impact on existing programs or processors. If fixed source form were deleted from a subsequent standard, existing programs in fixed source form would have to be converted to free source form. <REFLIST> <REF> X3J3/93-161 </REFLIST> <SUBMITTED BY> Richard Maine, maine@altair.dfrf.nasa.gov <HISTORY> | <EVENT> Jul 93, WG5 meeting: | 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 <VERSION> 1 <REQUIREMENT> Simplify Fortran 95 over Fortran 90 in (at least) the following ways. 1. Remove unnecessary restrictions such as a. all specification ordering restrictions in the <specification-part>, b. the maximum number of characters in a name, a line, a statement, c. the current disallowance of redundant specifications, and d. a number of other specific restrictions and constraints. 2. Remove those features identified as obsolescent in Fortran 90. 3. Make obsolescent those features associated with unduly complex syntax rules and/or constraints. Typical candidates are those parts (not necessarily all) of <char-selector>, <data-stmt>, and <common-stmt> that complicate the syntactical description of these features. <JUSTIFICATION> Computer language technology continues to advance in sophistication, both in terms of definition and implementation. The viable general purpose languages of the future will be powerful yet easy to use. The users of the future will tolerate neither restrictions due to primitive conceptual and technological legacies from the past nor syntactic complexity burdened with a plethora of arcane and unnecessary rules. <SUBMITTED BY> Jerry Wagener, jwagener@amoco.com <HISTORY> <EVENT> May 93: First proposal circulated via X3J3 email list by Jerry Wagener </HISTORY> </FORTREQ> ----------------------------------------------------------------------- <FORTREQ> <NUMBER> 023 <TITLE> User Defined Intrinsic Functions <KEYWORDS> INTRINSICS, CONSTANT EXPRESSIONS <STATUS> Registered <VERSION> 1 <REQUIREMENT> Provide a mechanism for user supplied functions to be used in contexts requiring a "constant expression", typically in specification statements. <JUSTIFICATION> Facilitates extensions to Fortran environments by other standard bodies, vendors, and Fortran implementers. NUMBER_OF_PROCESSORS () is an example of a "compile time" intrinsic which another standards body might wish to add. <COMPATIBILITY CONSIDERATIONS> None <REFLIST> <REF> X3J3/93-168 </REFLIST> <SUBMITTED BY> Rich Bleikamp for X3J3/parallel subgroup bleikamp@convex.com, 214-306-6393 </SUBMITTED BY> <HISTORY> | <EVENT> Jul 93, WG5 meeting: | Investigation for 1995 revision requested (B9 Resolution, item C3) <EVENT> May 93, meeting 125: Proposal X3J3/93-168 presented by Rich Bleikamp for X3J3/parallel subgroup </HISTORY> </FORTREQ> ----------------------------------------------------------------------- <FORTREQ> <NUMBER> 024 <TITLE> Nested WHERE Statements <KEYWORDS> WHERE STATEMENT, NESTING, PARALLELISM <STATUS> Registered <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/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> May 93, meeting 125: Proposal X3J3/93-167 presented by Rich Bleikamp. </HISTORY> </FORTREQ> ----------------------------------------------------------------------- <FORTREQ> <NUMBER> 025 <TITLE> Pure User Functions and Subroutines <KEYWORDS> FUNCTIONS, SIDE EFFECTS, FORALL, PARALLELISM <STATUS> Registered <VERSION> 1 <REQUIREMENT> Add support for user written "pure" functions and subroutines. This facilitates use of the block FORALL construct, by helping compilers parallelize the execution of FORALL. This requirement partially overlaps with another requirement, user defined elemental functions. <JUSTIFICATION> Requested by other Fortran related standards groups (HPFF). <COMPATIBILITY CONSIDERATIONS> None <REFLIST> <REF> X3J3/93-169 </REFLIST> <SUBMITTED BY> Rich Bleikamp for X3J3/parallel subgroup bleikamp@convex.com, 214-306-6393 </SUBMITTED BY> <HISTORY> | <EVENT> Jul 93, WG5 meeting: | 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> Registered <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> May 93, meeting 125: Proposal X3J3/93-171 presented by Rich Bleikamp. </HISTORY> </FORTREQ> ----------------------------------------------------------------------- <FORTREQ> <NUMBER> 027 <TITLE> Packaging Implementer Specific Intrinsics in MODULEs <KEYWORDS> INTRINSIC PROCEDURE, MODULE <STATUS> Registered <VERSION> 1 <REQUIREMENT> Provide a mechanism to package non-standard intrinsic packages in a portable way. Various other standard activities are specifying new intrinsics as extensions to Fortran, and significantly polluting the name space. Using modules to hide these intrinsics will help reduce name space pollution. <JUSTIFICATION> Facilitates extensions to Fortran environments by other standard bodies (e.g. HPFF, X3H5, POSIX). <COMPATIBILITY CONSIDERATIONS> None <REFLIST> <REF> X3J3/93-170 <REF> High Performance Fortran <REF> X3H5 document </REFLIST> <SUBMITTED BY> Rich Bleikamp for X3J3/parallel subgroup bleikamp@convex.com, 214-306-6393 </SUBMITTED BY> <HISTORY> <EVENT> May 93, meeting 125: Proposal X3J3/93-170 presented by Rich Bleikamp for X3J3/parallel subgroup </HISTORY> </FORTREQ> ----------------------------------------------------------------------- <FORTREQ> <NUMBER> 028 <TITLE> Binding to IEEE 754 <KEYWORDS> ARITHMETIC, FLOATING POINT, IEEE 754, BINDING <STATUS> Registered <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> 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> Jul 93, WG5 meeting: | Removal of conflicts recommended for 1995 revision (resolution B9, | item B2); investigation of full support in 1995 requested | (resolution B9, item C4) <EVENT> May 93: Proposal X3J3/93-162 prepared by Keith Bierman </HISTORY> </FORTREQ> ----------------------------------------------------------------------- <FORTREQ> <NUMBER> 029 <TITLE> Interline Optimization <KEYWORDS> OPTIMIZATION, REORDER, BLOCKS <STATUS> Registered <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> May 93: Proposal prepared by Keith Bierman </HISTORY> </FORTREQ> ----------------------------------------------------------------------- <FORTREQ> <NUMBER> 030 <TITLE> Variable Rank Arrays <KEYWORDS> ARRAY, RANK <STATUS> Registered <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> Efficient Varying Length Character Type <KEYWORDS> VARYING LENGTH, CHARACTER, MAXIMUM LENGTH <STATUS> Registered <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> X3J3/93-173 <REF> X3J3/93-166 <REF> ISO/IEC JTC1/SC22/WG5-N846 </REFLIST> <SUBMITTED BY> X3J3 <HISTORY> <EVENT> May 93, Meeting 125: Proposal drafted by Janice Shepherd, X3J3/93-173. </HISTORY> </FORTREQ> ----------------------------------------------------------------------- <FORTREQ> <NUMBER> 032 <TITLE> POSIX Binding to Fortran 90 <KEYWORDS> POSIX, BINDING, FORTRAN 90, FORTRAN 77 <STATUS> Registered <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> May 93: Proposal drafted by Len Moss </HISTORY> </FORTREQ> ----------------------------------------------------------------------- <FORTREQ> <NUMBER> 033 <TITLE> Object Oriented Fortran, OOF <KEYWORDS> OBJECT ORIENTED, OOF <STATUS> Registered <VERSION> 1 <REQUIREMENT> Add an Object Oriented capability to Fortran, OOF. The requirements listed below cannot be considered absolute. The X3J3 OOF Subcommittee has done the work to define this initial set of OOF capabilities. The set of language extensions (syntax and semantics) required to accomplish these features needs to be defined. This will be an iterative process since writing some code using the features may dictate changes. The OOF Subcommittee has defined the following requirements which are divided into four groups: Required for the 1995 draft, Hoped for in the 1995 draft, Some later draft, and Guidelines. I. In order to meet market demand, this group is required to be a part of the 1995 draft. A. Micro encapsulation (type definitions) and macro encapsulation (modules). B. Inheritance. C. Constructors and destructors. There are two additional points about this feature: Are they optional or mandatory? Does the constructor design also solve the pointer initialization problem (requirement 013)? II. This group of requirements would be nice to have in 1995 but are not required for an initial implementation. A. User Defined Polymorphism. The OOF user must be able to define different method implementations for different data types. B. Abstract classes (i.e., the class has no instantiations) and abstract methods (i.e., no implementation of the method exists at the class level where the method is defined). III. This last group of requirements has the least priority, they may or may not become a part of the language, and they may not be ready for the 1995 draft. A. A carefully coded OOF library is applicable to all types, e.g., a binary tree library would be applicable to all types. Note: C++ templates. B. OOF procedures may have an "inline" attribute. C. Persistent objects. D. Multiple inheritance. IV. Guidelines. A. If necessary, a subset should be accomplished for the 1995 draft, i.e., something should go into the 1995 draft. B. Syntax and semantics must impose the OOF discipline. C. The user of an OOF library must not require source. D. Fortran is a performance oriented language, OOF must not lose sight of this aspect of the language. E. Both compile-time and run-time bindings. F. Pointer and nonpointer (use local variables to create an instance of a derived type) based objects. G. Compile-time type checking where applicable. H. Minimize the changes to Fortran. <JUSTIFICATION> The OOPs paradigm is of growing importance in the programming community. <SUGGESTED IMPLEMENTATION> To be accomplished after WG5 authorization. <COMPATIBILITY CONSIDERATIONS> OOF must have the ability that a carefully coded library may be extended by a programmer using inheritance. <REFLIST> <REF> OOF View Graphs, X3J3/93-068 <REF> Object Oriented Fortran, OOF, X3J3/93-120 <REF> OOF, Making your favorite language object-oriented, X3J3/93-141 </REFLIST> <SUBMITTED BY> X3J3 Object Oriented Subcommittee <HISTORY> | <EVENT> Jul 93, WG5 meeting: | Investigation for 1995 revision requested (B9 Resolution, item C6) <EVENT> May 93, Meeting 125: Proposal for OOF requirement worked out; final draft submitted by Tom Lahey. <EVENT> Feb & May 93, Meetings 124 & 125: OOF subcommittee held meetings and also arranged for well qualified speakers to give OOPs seminars to the full committee. <EVENT> Nov 92, Meeting 123: X3J3 chartered the OOF Subcommittee (see X3J3/92-310). </HISTORY> </FORTREQ> ----------------------------------------------------------------------- <FORTREQ> <NUMBER> 034 <TITLE> Variable Repeat Specifiers in Formats <KEYWORDS> FORMAT <STATUS> Registered <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> 14 Jun 93: Proposal received. </HISTORY> </FORTREQ> ----------------------------------------------------------------------- <FORTREQ> <NUMBER> 035 <TITLE> Specifying Default Precisions <KEYWORDS> DEFAULT REAL DOUBLE PRECISION KIND <STATUS> Registered <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> 5 Jul 93: Proposal received. </HISTORY> </FORTREQ> ----------------------------------------------------------------------- <FORTREQ> <NUMBER> 036 <TITLE> MAXLOC and MINLOC To Accept CHARACTER Arguments <KEYWORDS> MAXLOC MINLOC CHARACTER <STATUS> Registered <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> -----------------------------------------------------------------------