ISO/IEC/JTC1/SC22/WG5-N1649 Repository of Requirements Version of 26 January 2006 (WG5 Standing Document 5) This standing document is the vehicle by which WG5 manages the specification of requirements for future revisions of the Fortran standard. It is a working document of WG5. This version is specifically intended for use at the February 2006 WG5 meeting. It represents the status of requirements as decided by WG5 at the conclusion of the previous (May 2005) WG5 meeting. It includes all the items considered at that meeting, which were contained in N1626, plus the new items submitted to WG5 since then, together with a brief indication of more recent technical progress. It does not contain a full list of references to recent J3 papers; this is given in J3 paper 06-010. To distinguish administrative and technical progress, the former 'Status' heading has been split into 'WG5 Status' and 'Development Status'. The Severity Level is defined in N1594. WG5 status is shown in the following table by: 1 - first priority, 2 - second priority, N - no decision taken yet, R - rejected. ------------------- Contents of Repository (Reference number, severity level, WG5 status, title) J3-001 3 1 Enhanced STOP J3-002 3 N GET_IO_UNIT J3-003 4 1 EXECUTE_COMMAND_LINE J3-004 3 N STORAGE_SIZE J3-005 3 N C_SIZEOF J3-006 3 N Find all available logical and character kinds J3-007 3/4 R Construct Name Local to Construct J3-008 3 2 Rewrite attribute requirements J3-009 4 2 IO_UNIT standard derived type J3-010 3 1 Allow empty CONTAINS part J3-011 5 R Coroutines J3-012 4 2 Use ALLOCATABLE and POINTER attributes in generic resolution J3-013 4 1 Internal subprograms as actual arguments and procedure pointer targets J3-014 6 2 Parameterized module facility J3-015 4 2 Updating complex parts J3-016 4 N Disassociated or deallocated actual argument associated with nonpointer nonallocatable optional dummy argument is considered not to be present J3-017 4 R Default initial values for absent optional dummy arguments J3-018 4 2 Non-null initial targets for pointers J3-019 4 1 More mathematical functions J3-020 3 1 Allow TYPE ( ) J3-021 4 R Resolve generic without invoking a procedure or evaluating arguments J3-022 4 2 Allow a polymorphic allocatable variable in intrinsic assignment J3-023 3 2 Named rank-one array constant's extent from its . J3-024 3 2 EXIT from any labeled construct J3-025 3 N Allow SUBROUTINE or FUNCTION to be optional on END statements for module and internal subprograms J3-026 3 N ATAN with two arguments works like ATAN2 J3-027 3 1 ASCII arguments for LGE etc J3-028 3 N Allow forward type for allocatable components J3-029 3 N More information about GET_COMMAND[_ARGUMENT] failure J3-030 3 N Simplified means to select the most commonly desired real and integer kinds J3-031 4 R ANDTHEN and ORELSE pseudo-functions J3-032 3 N Findloc J3-033 3 N Compiler Version J3-034 3 N Mold on Allocate J3-035 3 N Proposed f2k+ MTE on semicolons J3-036 4 R Use, Except J3-037 4 R Pointers and Targets J3-038 4 2 Libm: Bessel, erf, gamma, hypot J3-039 4 1 Rank > 7 J3-040 4 R Compute if actual arg is present J3-041 4 2 Interoperability of pointers, allocatables, and assumed-shape arrays J3-042 4 2 Interoperability of optional arguments J3-043 5 1 Pointers to contiguous mem J3-044 4 1 New Intents J3-045 5 R Same Assumed Shape declaration J3-046 5 1 DO CONCURRENT construct J3-047 7 2 TYPELESS objects (BITS) J3-048 4 2 Writing Comma Separated Value CSV files J3-049 4 R Select between expressions RU-001 3 1 Remove restriction on the maximum rank of arrays RU-002 3 2 Extend the semantics of the EXIT statement RU-003 4 1 Extend the obsolescent features list RU-004 >4 R Subset of Fortran Standard which does not include redundant features RU-005 4/5 2 Extend a set of array intrinsic functions RU-006 2 N Give a table with attribute compatibility UK-001 6 1 Co-array Fortran for parallel programming UK-002 3 1 Decimal floating point arithmetic UK-003 4 2 Conformance to IEEE 754R UK-004 3 N KIND environment specification UK-005 4 1 Long Integers UK-006 4 N Multiple Nonzero-Rank Part References UK-007 4 1 Pointer function references as actual arguments UK-008 4 2 Pointer function references as lhs in assignment UK-009 3 2 Use procedureness in generic resolution UK-010 3/4 R Partial initialization of PARAMETERs UK-011 3/4 N Elemental procedures that are not pure UK-012 3 N Recursive I/O ------------------- Changes from N1626 to N1649: There are two new items, UK-011 and UK-012, which have been amplified relative to the versions in email message SC22WG5.3329. There are detailed changes to status lines as described above. Where a requirement was accepted after modification, the modifying text is generally incorporated herewith except for particularly large items where a reference is given instead. ------------------- Number: J3-001 Title: Enhanced STOP Submitted By: J3 WG5 Status: Accepted as first priority item, May 2005 Development Status: Specification, syntax, edits complete Severity Level : 3 References: 04-007 8.4 STOP Statement page 170 04-107, 04-319r2 Basic Functionality: Trivially enhance the STOP statement for modern processors Rationale: The current STOP statement is vaguely defined, and has not been updated in accordance with modern practice. Furthermore, its syntax is peculiarly limited, going back to Fortran 66 days. Estimated Impact: At 167, J3/JoR estimated the impact as "Trivial". This is recorded in 04-265r1. Discussion: Modern practice suggests that (a) the stop code should be written to the standard error unit (b) an integer stop code should be returned as the process exit status. There are four peculiarities of STOP syntax: (1) An integer stop code is limited to 5 digits. (2) An integer stop code must be a literal constant, it cannot be a named constant. (3) A stop code must be a literal or named constant, it cannot be a constant (i.e. initialization) expression. (4) A stop code must be constant, it cannot be a non-constant expression. This paper advocates lifting all of these restrictions. Lifting all of them probably has less impact (or at least no more impact) than releasing some of them, as the processor can then simply use its normal expression evaluation mechanism. Detailed Specification: (1) The stop code shall be allowed to be a scalar initialization expression of type default integer or default character. (2) Recommend that the stop code be displayed on ERROR_UNIT. (3) Recommend that if the stop code is of integer type, it should be used as the process exit status (if the processor even has such a concept). (4) Note that the processor might use only a portion of such a stop code for the exit status. History: Paper 04-102 meeting 167 Submitted 04-319r2 169 Accepted as complete ------------------------------------------------------------------ Number: J3-002 Title: GET_IO_UNIT Submitted By: J3 WG5 Status: Decision deferred, May 2005 Development Status: Specification complete Severity Level : 3 References: 04-107, 04-186, 04-328 Basic Functionality: Add an procedure to ISO_FORTRAN_ENV to return a logical unit number which may be opened. Rationale: Logical unit numbers are processor-dependent, some method of getting one should be supported. Some programs (for example, multithreaded programs) may want units to be distributed according to a rule (for example, 1000 times thread number plus offset). Thus, some flexibility should be part of this intrinsic. Estimated Impact: The impact was estimated by J3/JoR at 167 as Trivial. Detailed Specification: See paper 04-327 regards possible renumbering of 13.8.2. These edits assume that paper passes. [360:33++] Add: "13.8.2.2.x GET_IO_UNIT( UNIT, [ NOTUNIT, MINUNIT, MAXUNIT, IOSTAT, IOMSG ] ) *Description.* Return values that exist, are not connected to an external file, and can be connected to an external file. *Class.* Subroutine. *Arguments.* UNIT shall be of type integer and may be of any rank. It is an INTENT(OUT) argument. It is assigned values of logical units that exist, are not connected to an external file, and can be connected to an external file. It shall not be assigned a value equal to INPUT_UNIT, OUTPUT_UNIT or ERROR_UNIT. If it is scalar, one value is returned; if it is an array, SIZE(UNIT) unique values are returned. NOTUNIT shall be of type integer. It shall (optional) be a scalar or a rank 1 array. It is an INTENT(IN) argument. The value of UNIT, or an element of UNIT if it is an array, shall not be equal to the value of NOTUNIT, or any element of NOTUNIT if it is an array. MINUNIT shall be a scalar of type integer. (optional) It is an INTENT(IN) argument. The value of UNIT, or an element of UNIT if it is an array, shall not be less than the value of MINUNIT. MAXUNIT shall be a scalar of type integer. (optional) It is an INTENT(IN) argument. The value of UNIT, or an element of UNIT if it is an array, shall not be greater than the value of MAXUNIT. IOSTAT shall be a scalar of type default integer. (optional) It is an INTENT(OUT) argument. It is assigned the value zero if the variable associated with UNIT contains valid values and assigned a processor-dependent positive value otherwise. IOMSG shall be a scalar of type default character. (optional) It is an INTENT(INOUT) argument. It is assigned a processor-dependent error message if the value of the variable associated with the IOSTAT argument indicates an error occurred. Otherwise, its value is unchanged." History: Paper 04-107 meeting 167 Submitted {same as 04-186} 04-328 168 Accepted as complete ------------------------------------------------------------------ Number: J3-003 Title: EXECUTE_COMMAND_LINE Submitted By: J3 WG5 Status: Accepted as first priority item, May 2005 Development Status: Specification, edits complete Severity Level : 4 References: 04-106, 04-329r3 Basic Functionality: Add a procedure to ISO_FORTRAN_ENV to cause an external program to execute. Rationale: Most processors provide a means to execute an external program, but the syntax varies. Furthermore, some processors may support only synchronous execution of external programs, so this processor limitation must be taken into account. Some programs may want to execute another program to generate an input file or to operate jointly via a pipe, thus program control over synchronous versus asynchronous execution should be supplied to some extent. Estimated Impact: The impact was estimated by J3 at 167 as Small. Detailed Specification: Executes a command line externally to the program. Whether the command line is interpreted by a shell is unspecified. Require synchronous execution and allow asynchronous execution. If synchronous execution, allow recovery of the executed process exit status. Allow processor-dependent error conditions. See paper 04-327 regards possible renumbering of 13.8.2. These edits assume that paper passes. [360:33++] Add: "13.8.2.2.x EXECUTE_COMMAND_LINE( COMMAND, [ WAIT, EXITSTAT, CMDSTAT, CMDMSG ] ) *Description.* Execute the command line identified by the string COMMAND. The processor must support synchronous and may support asynchronous execution of the external program. *Class.* Subroutine. *Arguments.* COMMAND shall be of type default character and shall be a scalar. It is an INTENT(IN) argument. It identifies the command line to be executed. The interpretation is processor-dependent. WAIT shall be of type default logical and shall (optional) be a scalar. It is an INTENT(IN) argument. When present and true, EXECUTE_COMMAND_LINE returns after the indicated command line has completed execution. When present and false, EXECUTE_COMMAND_LINE returns after the indicated command line has started execution. When not present, the effect is as if present with a value of true. EXITSTAT shall be of type default integer and shall (optional) be a scalar. It is an INTENT(INOUT) argument. It shall not be present if WAIT is present with a value of false. If WAIT is present with a value of true, the value of EXITSTAT is the processor-dependent exit status of the command line, if available. Otherwise, the value is unchanged. CMDSTAT shall be of type default integer and shall (optional) be a scalar. It is an INTENT(OUT) argument. It is assigned the value zero if no error occurred during EXECUTE_COMMAND_LINE and assigned a processor-dependent positive value otherwise. If an error occurs and CMDSTAT is not present, execution of the program terminates. If the processor does not support the concept of command lines, the value is 1. CMDMSG shall be of type default character and shall (optional) be a scalar. It is an INTENT(INOUT) argument. It is assigned a processor-dependent error message if the value of the variable associated with the CMDSTAT argument indicates an error occurred. Otherwise, the value of CMDMSG is unchanged." History: Paper 04-106 meeting 167 Submitted 04-329r3 169 Accepted as complete ------------------------------------------------------------------ Number: J3-004 Title: STORAGE_SIZE Submitted By: J3 WG5 Status: Decision deferred, May 2005 Development Status: Specification complete Severity Level : 3 References: 04-120, 04-342 Basic Functionality: Add a procedure to ISO_FORTRAN_ENV to return the size in bits of its argument. Rationale: There are situations where a program needs to know the size of an entity. Estimated Impact: The impact was estimated by J3 at 167 as Small. Detailed Specification: A procedure to return the size in bits of its argument. See paper 04-327 regards possible renumbering of 13.8.2. These edits assume that paper passes. [125:41+] Add list item "(4+) the intrinsic module function STORAGE_SIZE," [360:33+++] Add section "13.8.2.2.x STORAGE_SIZE (X [, KIND]) *Description.* Returns the storage size in bits for a nonpointer nonallocatable scalar of the declared type of X. *Class.* Inquiry function. *Arguments.* X may be of intrinsic or derived type. It shall not be polymorphic. If it is of derived type, that type shall be a SEQUENCE or interoperable type and shall have no allocatable ultimate components. If its type has any deferred type parameters, it shall be a pointer that is associated or an allocatable object that is allocated. It may be a scalar or an array. KIND (optional) shall be a scalar integer initialization expression. *Result Characteristics.* Integer scalar. If KIND is present, the kind type parameter is that specified by the value of KIND; otherwise, the kind type parameter is that of default integer type. *Result Value.* The result value is the size in bits of the storage unit (16.4.3.1) in a storage association context for a nonpointer nonallocatable scalar with the declared type and type parameters of X. *Example.* STORAGE_SIZE(1.0) returns the number of bits required to store an entity of type default real." History: Paper 04-120 meeting 167 Submitted {also N1539} 04-342 169 Accepted as complete ------------------------------------------------------------------ Number: J3-005 Title: C_SIZEOF Submitted By: J3 WG5 Status: Decision deferred, May 2005 Development Status: Specification complete Severity Level : 3 References: 04-104, 04-344r1 Basic Functionality: Add a procedure to ISO_C_BINDING to return the size of its argument as per C sizeof. Rationale: There are situations where a program needs to know the size of an entity, as expressed in C. Estimated Impact: The impact was estimated by J3 at 167 as Small. Detailed Specification: A procedure to return the size of its argument as per C. [125:41+] Add list item "(4++) the intrinsic module function C_SIZEOF," [395:31+++] (after the Note) Add section "15.1.2.6 C_SIZEOF (X) *Description.* Returns the size, as defined by the C sizeof operator (Section 6.5.3.4 of the C International Standard), of the argument X. *Class.* Inquiry function. *Arguments.* X X shall have interoperable type and type parameters. It may be a scalar or an array that is not assumed-size. *Result Characteristics.* Integer scalar of kind C_SIZE_T (15.2.1). *Result Value.* The result value is the size of X as defined by the sizeof operator (Section 6.5.3.4 of the C International Standard) of the companion C processor. If the companion processor is not a C processor, the result value is processor dependent." History: Paper 04-104 meeting 167 Submitted 04-344r1 169 Accepted as complete ------------------------------------------------------------------ Number: J3-006 Title: Find all available logical and character kinds Submitted By: J3 WG5 Status: Decision deferred, May 2005 Development Status: Specification complete Severity Level : 3 References: 04-121, 04-346r2 Basic Functionality: Add constants to iso_fortran_env which specify all available logical kind values and all available character kind names. Rationale: A program (subject or not to preprocessing) or an automatic code generator may have a preferred kind or a preferred ranking of possibly available kinds for entities of logical and character type. Currently, the only means available is to read the documentation and manually add the specific values needed. For example, a very large frequently used but infrequently updated logical array may be best expressed as an array of the smallest kind of logical. Default logical may exhaust the processor's fastest cache, leaving no space for numerical data. What is the smallest logical available? There is no automatically available answer now. Estimated Impact: The impact was estimated by JoR at 167 to be trivial. Only iso_fortran_env is affected. Detailed Specification: [360:4a+] "13.8.2.1- CHARACTER_KIND_NAMES The values of the default character rank 1 array CHARACTER_KIND_NAMES are the names, when any trailing blanks are removed, which may be passed to the SELECTED_CHAR_KIND procedure to obtain a valid kind value. The lower bound of CHARACTER_KIND_NAMES is one; the size of CHARACTER_KIND_NAMES is the number of character names supported by the processor. The names are stored in non-decreasing order of storage size of objects of the corresponding kind." [360:26+] Add "13.8.2.6+ LOGICAL_KIND_VALUES The values of the default integer rank 1 array LOGICAL_KIND_VALUES are the kind values of all available logical kinds. The lower bound of LOGICAL_KIND_VALUES is one; the size of LOGICAL_KIND_VALUES is the number of logical kind values supported by the processor. The values are stored in non-decreasing order of storage size of objects of the corresponding kind." History: Paper 04-121 meeting 167 Submitted 04-346r2 169 Accepted as complete ------------------------------------------------------------------ Number: J3-007 Title: Construct Name Local to Construct Submitted By: J3 WG5 Status: Rejected, May 2005 Development Status: Specification complete Severity Level : 3/4 References: 04-158, 04-348r1 Basic Functionality: Make a construct name be local to its construct. Rationale: Construct names are only referenced from within the construct. Therefore, it makes sense to use a construct scope for the name. Further, within a local scope, a construct name might naturally be desirable more than once. For example, within a local scope, an if-block might naturally be named "check_iostat" following more than one statement containing an iostat specifier, or more than one do-construct might be naturally named "all_rows", "all_columns", or "all_planes", etc. Of course, for cycle and exit to work properly, nested constructs must all have names unique within the nest. Estimated Impact: 3 or 4. Detailed Specification: (1) Define a construct name to have construct scope. (2) Remove construct names from all local entity classes, so that it can be the same as any local name and any global name. (3) Nested constructs shall not have the same name. (Note: after removal from local entities, this needs to be explicitly stated in the standard.) Incomplete Illustrative Edits: [406:4-5] remove "named constructs," [409:29+] add new paragraph "The name of a named construct has a scope of that construct. It may be the same as any local identifier or global identifier. The of a contained named construct shall not be the same as a of any of its containing named constructs." History: Paper 04-158 meeting 167 Submitted 04-348r1 169 Accepted as complete ------------------------------------------------------------------ Number: J3-008 Title: Rewrite attribute requirements Submitted by: Malcolm Cohen WG5 Status: Accepted as second priority item, May 2005 Development Status: Specification complete Severity Level : 3 References: 04-359 Basic Functionality: None. Rationale: The current method of specifying the requirements on various attributes, such as EXTERNAL and POINTER, is too hard to understand and too prone to error. Estimated impact: Non-trivial Editorial. Detailed Specification: Rewrite the attribute specification parts of chapters 5 and 12 so that (1) the syntax just says what attribute it provides (2) there is a separate attribute section which (a) contains the requirements (like "must be a dummy argument for VALUE") (b) describes the effects. History: Paper 04-359 meeting 169 Submitted 04-359 170 Accepted as complete ------------------------------------------------------------------ Number: J3-009 Title: IO_UNIT standard derived type Submitted By: J3 WG5 Status: Accepted as second priority item, May 2005 Development Status: Specification complete Severity Level : 4 References: 04-369 Requirements: Have a mechanism for i/o units that - does not confuse i/o units with integers (improved abstraction) - does not require the user to manage their use (ease of use) - avoids clashes between user-written code and existing third-party libraries - avoids race conditions in multi-threaded programs, without requiring the routine being used in a multi-threaded program to have different code (viz explicit calls to locking routines) from when it is being used without a threading library. Basic Functionality: Add a derived type to ISO_FORTRAN_ENV to represent an i/o unit. Allow values of this type to be used everywhere that a unit number can be used. Rationale: Logical unit numbers are processor-dependent, managing their use is difficult. Integer values are not a good model of a file handle. Simply finding a currently unused integer value is not sufficiently powerful to avoid known problems with clashes and race conditions - having a standard intrinsic to return an unused unit number can not help in this regard, no matter how sophisticated we make the intrinsic. Estimated Impact: Not Quite Trivial. Detailed Specification: (1) That a standard derived type, in the intrinsic module ISO_FORTRAN_ENV, be provided to represent file handles. This derived type is referred to as IO_UNIT hereafter. (2) That the IO_UNIT type be opaque. (3) That OPEN not be required to take a file unit number, but allowed to return an IO_UNIT value instead. (4) That an IO_UNIT value be usable in place of a in all other i/o statements. (5) That derived-type i/o subroutines not be modified; these will continue to receive some processor-determined negative number for the unit - because these are supplied by the processor and therefore cannot clash with user-determined unit numbers, this is not a problem. Syntax: (1) That the derived type be named IO_UNIT. (2a) That the UNIT= specifier on the OPEN be allowed to take a TYPE(IO_UNIT) variable instead of an integer value, or (2b) That a new specifier IO_UNIT= be allowed on OPEN if the UNIT= specifier is omitted. Edits: would be premature in the absence of an agreed base document. Sections needing modification are: 9.4.0 The unit definition 9.4.5 the description of OPEN 13.8.2 to mention the derived type. History: Paper 04-369 meeting 169 Submitted 04-369 170 Accepted as complete ------------------------------------------------------------------ Number: J3-010 Title: Allow empty CONTAINS part Submitted By: J3 WG5 Status: Accepted as first priority item, May 2005 Development Status: Specification, syntax, edits complete Severity Level : 3 References: 04-189, 04-379 Basic Functionality: Allow empty CONTAINS part Rationale: Is there a good reason that a module, procedure or type definition has to have procedure definitions after the CONTAINS statement? What would be hurt by allowing not to have any? Sometimes when programs are generated automatically, they end up with an empty CONTAINS part, and then you have to go fix it manually, or whine (ineffectually) to the unsympathetic guys who wrote the processor (if they're still in business), for which you have no source code. It's also not unreasonable to start off development of a module or type with an empty CONTAINS part, with the intent of filling it in later. Estimated Impact: Trivial. Change a few syntax rules. No new words needed anywhere. Estimated at J3 meeting 169 to be at 3 on the JKR scale. Detailed Specification: Allow an empty CONTAINS part in external and module procedures, modules, and derived type definitions. History: Paper 04-189 meeting 167 Submitted 04-379 170 Accepted as complete ------------------------------------------------------------------ Number: J3-011 Title: Coroutines Submitted By: J3 WG5 Status: Rejected, May 2005 Development Status: Specification complete Severity Level : 5 References: 04-345, 04-380r2 Basic Functionality: Provide for coroutines. Rationale: In many cases when a "library" procedure needs access to user-provided code, the user-provided code needs access to data of which the library procedure is unaware. There are at least three ways by which the user-provided code can gain access to these entities: o The user-provided code can be implemented as a procedure that is invoked by the library procedure, with the extra data stored in globally-accessible variables. o The user-provided code can be implemented as a procedure that takes a dummy argument of extensible type, which procedure is invoked by the library procedure, with the extra entities in an extension of that type. o The library procedure can provide for "reverse communication", that is, when it needs access to user-provided code it returns instead of calling a procedure. When the user-provided code reinvokes the library procedure, it somehow finds its way back to the appropriate place. Each of these solutions has drawbacks. Entities that are needlessly public increase maintenance expense. If the user-provided procedure expects to find its extra data in an extension of the type of an argument passed through the library procedure, the dummy argument has to be polymorphic, and the user-provided code has to execute a SELECT TYPE construct to access the extension. Reverse communication causes a mess that requires GO TO statements to resume the library procedure where it left off, which in turn requires one to simulate conventional control structures using GO TO statements. This reduces reliability and increases development and maintenance costs. Reverse communication is, however, a blunt-force simulation of a well-behaved control structure that has been well-known to computer scientists for decades: The "coroutine". Coroutines would allow user-provided code needed by library procedures more easily to gain access to data of which the library procedure is unaware, without causing the disruption of the control structure of the library procedure that reverse communication now causes. Coroutines are useful to implement "iterator" procedures, that can be used both to enumerate the elements of a data structure and to control iteration of a loop that is processing those elements. Estimated Impact: Minor additions to Subclause 2.3.4 and Section 12. Estimated at J3 meeting 169 to be at 5 on the JKR scale. Detailed Specification: Provide two new statements, which we here call SUSPEND and RESUME. Provide a new form of subprogram, the "coroutine", that cannot contain an ENTRY statement, and is the only subprogram in which a SUSPEND statement is allowed. A coroutine requires an explicit interface. Coroutines can stand on their own, or be type-bound procedures or actual arguments. They can be procedure pointer targets, provided the pointer has explicit interface. Generic coroutines are allowed, provided the is . Recursive and internal coroutines are allowed. When a coroutine is invoked by a CALL statement, execution continues with the coroutine's first executable construct. When a coroutine executes a SUSPEND statement, execution continues after the CALL or RESUME statement that initiated or resumed its execution; when a RESUME statement is executed, execution resumes after the SUSPEND statement. When a coroutine executes a RETURN or END statement, execution continues after the CALL or RESUME statement that initiated or resumed its execution, and it is an error if one later attempts to RESUME it without first calling it. A type-bound coroutine shall be initiated using a variable, and resumed using the same variable. A coroutine that is initiated using a pointer shall be resumed using the same pointer. Otherwise, a coroutine shall be resumed from the same scoping unit in which it is initiated. Data entities: Variables within a coroutine can have the SAVE attribute, with the usual implications. Unsaved local variables within a coroutine retain their definition status and values from SUSPEND to RESUME. Automatic objects in addition retain their bounds and length parameter values. The specification part is not elaborated upon resumption. If a coroutine references a module or common block, it is considered to continue to reference it between SUSPEND and RESUME. A change in the value of a variable between SUSPEND and RESUME does not affect the bounds or length parameter values of automatic variables within the coroutine. Argument association does survive execution of a SUSPEND statement. Activation records: The above rules guarantee that coroutines can be reentrant. The following paragraphs suggest one way to implement those rules. When a coroutine suspends execution by executing a SUSPEND statement, its activation record is saved. When a coroutine is resumed, its activation record is restored. Therefore there is no restriction on where a SUSPEND statement is allowed to appear among the executable constructs. A type-bound coroutine's activation record is saved in and restored from an extension of the variable by which its execution is initiated or resumed, i.e., in X, if it is referenced as X%C. If a coroutine is accessed by a procedure pointer, its activation record is saved in the pointer. Otherwise, the processor stores the activation record locally (so CALL and RESUME have to be in the same scoping unit). History: Paper 03-258r1 meeting 166 Submitted in section 1.1 04-149r1 167 04-345 169 04-380r2 170 Accepted as complete ------------------------------------------------------------------ Number: J3-012 Title: Use ALLOCATABLE and POINTER attributes in generic resolution Submitted By: J3 WG5 Status: Accepted as second priority item, May 2005 Development Status: Specification, edits complete Severity Level : 4 References: 04-170, 04-381 Basic Functionality: Use ALLOCATABLE and POINTER attributes in generic resolution Rationale: I have a generic interface ALLOCATE_TEST that allocates an object, tests the status, and prints an error message if an error occurs. I cannot have a specific interface for a to-be-allocated argument that has the POINTER attribute, and another for a to-be-allocated argument with the same type, kind type parameters and rank that has the ALLOCATABLE attribute. So I need different generic names for allocatable objects and pointer objects. If I change an object from pointer to allocatable or vice-versa, I have to track down all of the ALLOCATE_TEST invocations for that variable and change them to the other one. Avoiding this labor was one of the justifications for the generic facility. Estimated Impact: Minor. Estimated at J3 meeting 169 to be at 5 on the JKR scale. It is more likely at 3 on the JKR scale, since it appears that the only place where edits are necessary is 407:29. Detailed Specification: Allow the POINTER and ALLOCATABLE attributes to be used as the last resort for generic resolution: If the only difference between two specific interfaces is that in one there is a dummy argument that has neither the POINTER nor ALLOCATABLE attribute, and the corresponding argument in the other one has one of those attributes, the interface is ambiguous. If one has the POINTER attribute and the corresponding one has the ALLOCATABLE attribute the interface is not ambiguous, at least so far as that pair of specific procedures is concerned. If a dummy argument has the POINTER or ALLOCATABLE attribute, the corresponding actual argument is required to have the same attribute. Therefore this change would not invalidate any existing program. History: Paper 04-170 meeting 167 Submitted 04-381 170 Accepted as complete ------------------------------------------------------------------ Number: J3-013 Title: Internal subprograms as actual arguments and procedure pointer targets Submitted By: J3 WG5 Status: Accepted as first priority item, May 2005 Development Status: Specification, edits complete Severity Level : 4 References: 04-148, 03-258r1, section 1.7, 04-382r1 Basic Functionality: Allow internal subprograms as actual arguments and procedure pointer targets Rationale: In many cases where one uses a subprogram as an actual argument, it needs access to entities of which the procedure to which it is passed is unaware. If the actual argument were an internal subprogram, it could access these extra entities by host association. Since the 2003 standard does not require the TARGET attribute for a nonpointer dummy procedure that is a procedure pointer target, we cannot simultaneously allow internal procedures to be actual arguments and prohibit them to be procedure pointer targets. Estimated Impact: Small. Minor changes necessary in Sections 7, 12 and 16, and maybe Annex C. Estimated at J3 meeting 169 to be at 4 on the JKR scale. Detailed Specification: Allow an internal subprogram to be an actual argument: There are two possibilities concerning the host of the internal subprogram: o Allow the host of the internal subprogram to be recursive. Make it clear that accesses by host association from the internal subprogram to entities of its host are accesses to entities in the instance of its host as of the instant the internal subprogram was used as an actual argument, not to entities in the instance of its host as of the instant the internal subprogram is invoked. o Require that the host of the internal subprogram is not recursive. In this case, there can only be one instance of the procedure defined by the host subprogram. This restriction could later be relaxed. Many processors may relax it as an extension. Allow an internal subprogram to be a procedure pointer target: Similar considerations regarding recursive hosts apply. It is unavoidable that the same restriction applies to internal subprograms used as procedure pointer targets and used as actual arguments. If internal subprograms of recursive hosts are allowed to be procedure pointers, make it clear that the instance of the host to which accesses from the internal subprogram to that host by host association refer, when it is invoked by way of the pointer, is the instance as of the instant the procedure was associated with the pointer, which is not necessarily the instance as of the instant the internal subprogram is invoked via the pointer. Make sure that a procedure pointer associated with an internal subprogram becomes undefined when the instance of the procedure defined by its host subprogram that was in existence at the instant the pointer association was established ceases to exist. History: Paper 04-148 meeting 167 Submitted 04-382r1 170 Accepted as complete ------------------------------------------------------------------ Number: J3-014 Title: Parameterized module facility Submitted By: J3 WG5 Status: Accepted as second priority item after modification as per J3/05-181r1, May 2005 Development Status: Specification, syntax complete Severity Level : 6 References: 04-153, 04-383r1 Basic Functionality: Provide a facility whereby a module or subprogram can be developed in a generic form, and then applied to any appropriate type. Rationale: Many algorithms can be applied to more than one type. Many algorithms that can only be applied to one type can be applied to more than one kind. It is tedious, expensive, and error prone - especially during maintenance - to develop algorithms that are identical except for type declarations to operate on different types or kinds. Generic modules are useful to package types together with their type-bound procedures, so that when they are instantiated, they are consistent. This cannot be guaranteed for parameterized types. Estimated Impact: Moderate to extensive, depending on how it's done. The solution proposed here can be implemented mostly with changes in Section 11, and perhaps a few changes in Section 4. Estimated at J3 meeting 169 to be at 6 on the JKR scale. Detailed Specification: See J3/05-181r1 History: Paper 03-264r1 meeting 166 Submitted 04-153 167 04-383r1 170 Accepted as complete ------------------------------------------------------------------ Number: J3-015 Title: Updating complex parts Submitted By: J3 WG5 Status: Accepted as second priority item, May 2005 Development Status: Specification, syntax, edits complete Severity Level : 4 References: 04-165, 04-384r1 Basic Functionality: Provide a syntax that allows to update the real and imaginary parts of a complex variable without updating the whole thing Rationale: It's not unusual to need to do this. Estimated Impact: Very minor. Estimated at meeting 169 to be 4 on the JKR scale. Detailed Specification: Specify that the real and imaginary parts of a complex variable can be accessed by using component-like syntax, with "component" names REAL and AIMAG. History: Paper 03-258r1 meeting 166 Section 2.2.5 04-165 167 Submitted 04-255 167 04-384r1 255 Accepted as complete ------------------------------------------------------------------ Number: J3-016 Title: Disassociated or deallocated actual argument associated with nonpointer nonallocatable optional dummy argument is considered not to be present Submitted By: J3 WG5 Status: Decision deferred, May 2005 Development Status: Specification complete Severity Level : 4 References: 04-178, 04-385 Basic Functionality: A disassociated or deallocated actual argument associated with a nonpointer nonallocatable optional dummy argument is considered not to be present. Rationale: I have a procedure that has numerous pointers that are associated, or not, depending on input parameters. These are in turn passed to some subroutines that do (or do not do) some computations depending on whether the dummy arguments are associated. This, of course, requires the dummy arguments to be pointers, which degrades the generality of the procedure, and may have undesirable implications for optimization. It would be better if I could use optional nonpointer dummy arguments to decide whether to do these computations. In order to achieve this effect by using N optional dummy arguments I need an IF ... ELSE IF ... END IF construct with 2**N branches. Estimated Impact: Nearly trivial -- a minor change in definition of "present". Estimated at meeting 169 to be 4 on the JKR scale. Detailed Specification: Allow to associate a deallocated allocatable actual argument, or a disassociated pointer actual argument, with an optional nonpointer nonallocatable dummy argument, in which case the dummy argument is considered to be absent. In Fortran 2003, this is an error. History: Paper 03-258r1 meeting 166 Section 2.4.3.1 04-178 167 Submitted 04-385 170 Accepted as complete ------------------------------------------------------------------ Number: J3-017 Title: Default initial values for absent optional dummy arguments Submitted By: J3 WG5 Status: Rejected, May 2005 Development Status: Specification complete Severity Level : 4 References: 04-179, 04-386r2 Basic Functionality: Default initial values for absent optional dummy arguments Rationale: A frequently requested feature is to be able to specify a default initial value for absent optional dummy arguments. Estimated Impact: Minor; most changes are in Section 12. Estimated at J3 meeting 169 to be at 4 on the JKR scale. Detailed Specification: Provide a specification for a default initial value for an absent optional dummy scalar, or dummy array that is not an assumed-size array. The specification has exactly the same syntax as an initialization, but with a constraint that the expression shall be a restricted expression rather than an initialization expression. (The restrictions on specification expressions at [04-007:126:7-19] would need to be applied to restricted expressions in general instead of just to specification expressions.) If an optional dummy argument has a default initialization specified and the associated actual argument is absent, the initializer is evaluated on entry to the procedure, and then becomes associated with the dummy argument. The VALUE attribute may be specified as well. Optional dummy arguments with initializers cannot have INTENT(INOUT) or INTENT(OUT). For an optional dummy argument that has default initialization: (1) Its assumed nonkind type parameters and extents, and dynamic type if it is polymorphic, are taken from the initializer. (2) If it is not a pointer the value is assigned as if by intrinsic assignment. (3) If it is allocatable, it is assumed to be unallocated before initialization. (4) If it is a pointer, the default initializer shall have the POINTER or TARGET attribute, and the association is established as if by pointer assignment. History: Paper 03-258r1 meeting 166 Section 2.4.3.2 04-179 167 Submitted 04-386r2 170 Accepted as complete ------------------------------------------------------------------ Number: J3-018 Title: Non-null initial targets for pointers Submitted By: J3 WG5 Status: Accepted as second priority item, May 2005 Development Status: Specification, syntax, edits complete Severity Level : 4 References: 04-202, 04-387r1 Basic Functionality: Allow initial targets for pointers that are other than NULL(). Rationale: It would be useful to be able to initialize pointers to targets other than NULL(). This is especially true for procedure pointers. Estimated Impact: Minor. It was estimated to be at 3 on the JKR scale at meeting 169, but it is now clear that the project is a bit more complicated than originally envisioned. It was judged at J3 meeting 170 to be at 4 on the JKR scale. Detailed Specification: Allow the initial target for a data pointer to be an accessible nonpointer nonallocatable variable with the SAVE attribute. Every expression within the variable shall be an initialization expression. Allow the initial target for a procedure pointer to be an accessible external or module procedure, or an intrinsic procedure listed in subclause 13.6 and not marked with a bullet (or the result of resolving a generic without invoking a procedure if the proposal in 04-391 succeeds). The initial target shall satisfy all the requirements for pointer assignment (e.g. the TARGET attribute, type conformance, etc.). This feature shall be available both for named pointers and for pointer components. Pointer components may be default initialized to have an initial target. The target may be accessed by use or host association. If it is declared in the same scoping unit it need not have been previously declared; this facilitates initialization to a "sentinel" object. (See note 4.36 1/2 in section 8.1 in 04-387.) History: Paper 03-258r1 meeting 166 Section 2.12.2 04-202 167 Submitted 04-351 169 04-387r1 170 Accepted as complete ------------------------------------------------------------------ Number: J3-019 Title: More mathematical functions Submitted By: J3 WG5 Status: Accepted as first priority item, May 2005 Development Status: Specification, edits complete Severity Level : 4 References: 04-184, 04-388r1 Basic Functionality: More mathematical functions. Rationale: Mathematical functions for complex type are occasionally needed. The only ones that are available for complex type are ABS, COS, EXP, LOG, and SIN. The other mathematical functions that are provided for real type are useful in practice for complex type as well. Inverse hyperbolic functions and other functions are useful. Simple identities for complex argument exist, but it is a burden to expect users to look them up, and processors might be able to produce more efficient implementations. For inverse hyperbolic functions, there are simple identities involving square root and logarithm, but these can have substantial cancellation error for some ranges of values, so it is important to be careful in their implementation. Processors would presumably include careful intrinsic implementations of these functions. Estimated Impact: Minor but tedious. Estimated at meeting 169 to be 4 on the JKR scale. Detailed Specification: Provide ACOS, ASIN, ATAN, COSH, SINH, TAN and TANH for complex type. Provide inverse hyperbolic functions, including for complex type. In the case of TAN, specify that the real part of the argument is regarded as a value in radians. History: Paper 03-258r1 meeting 166 Section 2.4.4.3 04-184r1 167 Submitted 04-388r1 170 Accepted as complete ------------------------------------------------------------------ Number: J3-020 Title: Allow TYPE ( ) Submitted By: J3 WG5 Status: Accepted as first priority item, May 2005 Development Status: Specification, syntax, edits complete Severity Level : 3 References: 04-161, 04-389r1 Basic Functionality: Allow TYPE ( ). Rationale: For regularity and symmetry, allow TYPE ( ). Estimated Impact: Trivial. Estimated at meeting 169 to be at 3 on the JKR scale. Detailed Specification: Allow TYPE ( ) to declare entities of intrinsic type. History: Paper 03-258r1 meeting 166 Section 2.2.1 04-161 167 Submitted 04-389r1 170 Accepted as complete ------------------------------------------------------------------ Number: J3-021 Title: Resolve generic without invoking a procedure or evaluating arguments Submitted By: J3 WG5 Status: Rejected, May 2005 Development Status: Specification complete Severity Level : 4 References: 04-273, 04-391r1 Basic Functionality: Given examplars of actual arguments, resolve a generic name to a specific procedure without invoking the procedure or evaluating its arguments. Rationale: With care and diligence, one can develop a program so that related sets of variables, constants and function results are parameterized by a single kind type parameter. In order to change the kind of that set of entities, one need only change one named constant's definition - almost: Generic procedures cannot be actual arguments or procedure pointer targets. Thus, if one needs to change the program, in addition to changing the single named constant definition, one needs to find all places where a specific procedure that operates on the entities in question is an actual argument or procedure pointer target, and manually edit those appearances. It would be helpful to have a facility to resolve a generic name to a specific procedure without evaluating any arguments or invoking a procedure. Estimated Impact: Minor. Processors already know how to do generic resolution. Estimated at meeting 169 to be at 4 on the JKR scale. Detailed Specification: Given examplars of actual arguments, resolve a generic name to a specific procedure without invoking the procedure or evaluating its arguments. There are at least two ways to do this. One is to provide a syntax that is suggestive of procedure reference, but does resolution instead. One possibility for this is to enclose an actual argument list in square brackets or curly brackets instead of round brackets. E.g., call solver ( myVec, myJacobian, myModel[myVec,myJacobian] ) Another is to provide an entity that looks like an intrinsic function but that has the important distinction that its arguments aren't evaluated. Indeed, this entity that has the appearance of a function reference isn't even invoked during program execution. It is entirely resolved to a procedure by the processor during translation. E.g., call solver ( myVec, myJacobian, resolve(myModel,myVec,myJacobian) ) RESOLVE would be a an inquiry "function" that takes a as its first "argument," and doesn't evaluate its other arguments - because it's an inquiry function. It should be possible to resolve a type-bound generic reference, e.g., RESOLVE(A%B). No matter what syntax is used, it should be allowed to use the result either as an actual argument or a procedure pointer target. History: Paper 04-273 meeting 168 Submitted 04-391r1 170 Accepted as complete ------------------------------------------------------------------ Number: J3-022 Title: Allow a polymorphic allocatable variable in intrinsic assignment Submitted By: J3 WG5 Status: Accepted as second priority item, May 2005 Development Status: Specification, edits complete Severity Level : 4 References: 04-354r1, 04-392 Basic Functionality: Allow a polymorphic allocatable variable in intrinsic assignment. Rationale: We allow intrinsic assignment to change the extent or length type parameters of an allocatable variable in an assignment. Why not the type if it's also polymorphic? Surely that would be equally valuable. After all, it can be done with a DEALLOCATE statement followed by an ALLOCATE statement with a SOURCE= specifier. Why not allow the clearer intrinsic assignment statement? Estimated Impact: Trivial for the standard, probably in the trivial-to-small range for processors. Estimated at meeting 169 to be at 4 on the JKR scale. Detailed Specification: Allow a polymorphic allocatable variable in intrinsic assignment. Require to have the same rank as a polymorphic . If is allocated and polymorphic, deallocate it (as we do now if any bounds or length type parameters differ). Then allocate it with the same dynamic type, type parameters and bounds as . Or, we could say "if the dynamic type of is different from the dynamic type of , deallocate ". It is necessary to specify which one because if we do the first, processors could not choose to do the second as a polite optimization without making finalization indeterminate. There could be a middle ground that mumbles about finalizers. History: Paper 04-354r1 meeting 169 Submitted 04-392 170 Accepted as complete ------------------------------------------------------------------ Number: J3-023 Title: Named rank-one array constant's extent from its . Submitted By: J3 WG5 Status: Accepted as second priority item after modification as per J3/05-189, May 2005 Development Status: Specification, syntax, edits complete Severity Level : 3 References: 01-180, 04-101, 04-394r1 Basic Functionality: As with the length of a character named constant, allow a rank-one array named constant to get its extent from the . Rationale: There was a good reason that a provision was made for named constants of character type to get their lengths from their s. For the same reason, it would be useful if a rank-one array named constant could get its extent from its . Estimated Impact: Small effect in 5.1.2.5.2, or maybe a short new subclause in 5.1.2.5, to explain how an array named constant gets its extent from its (see item (2) in the list at the end of 4.4.4). Estimated at meeting 169 to be at 3 on the JKR scale. Detailed Specification: Original: Allow a rank-one array named constant to get its extent from the extent of its . Use for the dimension specification. See 01-180 for an example. After modification: Allow an array named constant to get its extents from the extents of its . The ranks of the named constant and its shall be the same. Use an asterisk for every dimension in the declaration of the named constant. History: Paper 01-180 meeting 156 04-101 167 Submitted 04-394r1 170 Accepted as complete ------------------------------------------------------------------ Number: J3-024 Title: EXIT from any labeled construct Submitted By: J3 WG5 Status: Accepted as second priority item, May 2005 Development Status: Specification, syntax, edits complete Severity Level : 3 References: 04-156, 04-395r1 Basic Functionality: Allow EXIT from any labeled construct. Rationale: Some algorithms cannot be expressed in Fortran 2003 without GOTO statements or extra tests, but they could be expressed with EXIT if it could be applied to any labeled construct. For example, here's a routine that says "call R if X is not an element of the set S, which is represented by elements of A(1:NUM\_IN\_SET)". With an extra test: do i = 1, num_in_set if ( x == a(i) ) exit end do ! i if ( i > num_in_set ) call r or, with GOTO: do i = 1, num_in_set if ( x == a(i) ) go to 10 end do ! i go to 20 10 call r 20 continue or, with a more general EXIT: o: if ( .true. ) then do i = 1, num_in_set if ( x == a(i) ) exit o end do ! i call r end if o Estimated Impact: Trivial to minor -- a few lines in 8.1.6.4.4. Estimated at meeting 169 to be at 3 on the JKR scale. Detailed Specification: Allow an EXIT statement with a that is the same as the name of any enclosing construct, not just a DO construct. When the EXIT statement is executed, execution of the named construct is terminated. For compatibility, an EXIT statement without a continues to refer to the nearest enclosing DO construct. History: Paper 03-258r1 meeting 166 Section 2.1.2 04-109 167 04-156r1 167 Submitted 04-395r1 170 Accepted as complete ------------------------------------------------------------------ Number: J3-025 Title: Allow SUBROUTINE or FUNCTION to be optional on END statements for module and internal subprograms Submitted By: J3 WG5 Status: Decision deferred, May 2005 Development Status: Specification complete Severity Level : 3 References: 04-177, 04-396r1 Basic Functionality: Allow SUBROUTINE or FUNCTION to be optional on END statements for module and internal subprograms. Rationale: Module procedures are required to end with END SUBROUTINE or END FUNCTION . This is generally a good thing, but it makes it impossible to convert a Fortran 77 external procedure to a module procedure by using INCLUDE. Estimated Impact: Trivial. Estimated at meeting 169 to be at 3 on the JKR scale. Detailed Specification: To cater for the desire that a Fortran 77 external procedure could be made into a module procedure using INCLUDE, allow the SUBROUTINE or FUNCTION part to be optional on an or statement. For consistency, allow them to be optional for internal subprograms as well. History: Paper 03-258r1 meeting 166 Section 2.4.2 04-177 167 Submitted 04-396r1 170 Accepted as complete ------------------------------------------------------------------ Number: J3-026 Title: ATAN with two arguments works like ATAN2 Submitted By: J3 WG5 Status: Decision deferred, May 2005 Development Status: Specification complete Severity Level : 3 References: 04-183, 04-397 Basic Functionality: Define an alternative ATAN that works like ATAN2. Rationale: ATAN is generic. It is surprising to students that they need to use ATAN2 just because they have the two-argument formulation. Estimated Impact: Minor: One more description for an existing intrinsic function - and we already have the description. Estimated at meeting 169 to be at 3 on the JKR scale. Detailed Specification: Provide a specification for how ATAN works with two arguments, based on how ATAN2 works. History: Paper 03-258r1 meeting 166 Section 2.4.4.2 04-183 167 Submitted 04-397 170 Accepted as complete ------------------------------------------------------------------ Number: J3-027 Title: ASCII arguments for LGE etc Submitted By: J3 WG5 Status: Accepted as first priority item, May 2005 Development Status: Specification, edits complete Severity Level : 3 References: 04-185, 04-398 Basic Functionality: Allow ASCII arguments for LGE etc. Rationale: Now that ASCII kind characters are required by the standard, it is nothing short of bizarre that the four functions to compare character strings according to the ASCII collating sequence, viz. LGE, LGT, LLE and LLT, do not permit arguments of ASCII kind. If one has a program with some character variables of default kind that are compared by using these functions, and their kind needs to be changed to ASCII, one has to find the invocations of these functions and replace them by the equivalent relational operators. This is an unnecessary maintenance expense. Estimated Impact: Trivial. Estimated at meeting 169 to be at 3 on the JKR scale. Detailed Specification: Allow ASCII kind arguments for LGE, LGT, LLE and LLT. History: Paper 03-258r1 meeting 166 Section 2.4.4.5, 04-185 04-185 167 Submitted 04-398 170 Accepted as complete ------------------------------------------------------------------ Number: J3-028 Title: Allow forward type for allocatable components Submitted By: J3 WG5 Status: Decision deferred, May 2005 Development Status: Specification complete Severity Level : 3 References: Pub-116, 04-226, 04-399 Basic Functionality: Do not require the type of an allocatable component to be defined before the type containing the allocatable component. Rationale: Mutually recursive types can be related by components having the POINTER attribute, which allows the types of the components to be defined after the type definition in which the components appear. Some mutually recursive types could be related by components having the ALLOCATABLE attribute, except that is presently prohibited. ALLOCATABLE is preferable to POINTER whenever possible. We should make every effort to make ALLOCATABLE as widely usable as possible. Estimated Impact: Easy to implement, improves performance, trivial change in the standard. Estimated at meeting 169 to be at 3 on the JKR scale. Detailed Specification: Do not require the type of an allocatable component to be defined before the type containing the allocatable component. The following suggested edits illustrate the magnitude of the proposal: In Constraint 438, replace "the POINTER attribute is not" by "neither the POINTER nor ALLOCATABLE attribute is" and delete "shall be CLASS(*) or" (Constraint 437 requires either the POINTER or ALLOCATABLE attribute for a component declared with the CLASS keyword). In Constraint 439, insert "or ALLOCATABLE" after "POINTER". History: Paper 04-226 meeting 167 Submitted as Pub-116 04-399 170 Accepted as complete ------------------------------------------------------------------ Number: J3-029 Title: More information about GET_COMMAND[_ARGUMENT] failure Submitted By: J3 WG5 Status: Decision deferred, May 2005 Development Status: Specification complete Severity Level : 3 References: 04-352, 04-400 Basic Functionality: Provide more information if GET_COMMAND or GET_COMMAND_ARGUMENT fails. Rationale: It would be useful to know more precisely why GET_COMMAND or GET_COMMAND_ARGUMENT fails. Estimated Impact: Trivial for standard, probably trivial-to-small for processors. Estimated at meeting 169 to be at 3 on the JKR scale. Detailed Specification: Set the STATUS argument of GET_COMMAND to -2 if the processor does not support the concept of a command line. Set the STATUS argument of GET_COMMAND_ARGUMENT to -2 if the value of the NUMBER argument is negative or more than the number of command arguments. History: Paper 04-352 meeting 169 Submitted 04-400 170 Accepted as complete ------------------------------------------------------------------ Number: J3-030 Title: Simplified means to select the most commonly desired real and integer kinds Submitted By: J3 WG5 Status: Decision deferred, May 2005 Development Status: Specification complete Severity Level : 3 References: 04-240, 04-407r1 Basic Functionality: Provide a simplified means to select the most commonly desired real and integer kinds. Rationale: Several possible approaches were outlined in 04-240. I propose that we adopt the approach that is intermediate in complexity, namely that the standard define named constants for the most commonly desired real and integer kinds. The approach of standardizing some named constants seems adequately simple without being restrictive or raising compatibility issues. It also has the advantage of being completely trivial to implement. My proposal is restricted to kinds with exact sizes. Adding too many options would increase the complexity of the choice to be made by users and would result in issues of interoperability of codes where different users made different choices of how to specify the kinds. Note that the existing selected_*_kind intrinsics provide the capability of specifying minimum requirements and could be extended in many ways (although that is not proposed here). Exact sizes are the simplest and most commonly requested requirement, and one that the standard currently provides no facility for (except in C interop, which has it only for integers - nor for reals). I also restrict the proposal to integers and reals because they are the common cases. User specification of specific sizes for logical kinds is rare (and even more rare when you rule out the cases where logical is being used as a synonym for unsigned integer, which is a nonstandard and nonportable practice anyway). User specification of character kinds is also rare. Estimated Impact: 3 on the JKR scale. Detailed Specification: The standard will specify the names of several named constants in the ISO_FORTRAN_ENV intrinsic module. These named constants will have kind values for the representations described below. Named constants provided will be for the kinds of integers whose storage sizes are exactly 8, 16, 32, and 64 bits, and for the kinds of reals whose storage sizes are exactly 32, 64, and 128 bits. Additionally, named constants will be provided for the kinds of default integer, default real, and double precision real. If the processor supports more than one representation with the specified size, it is processor-dependent which of those representations the named constant corresponds to. If the processsor does not support a particular representation, the value of the corresponding named constant will be one of two negative values specified by the standard. If the processor does not support a representation with the exact size requested or with any larger size, the value shall be -1. If the processor does not support a representation with the exact size requested, but does support a representation with a larger size, the value shall be -2. This proposal does not require the compiler to support any particular kind. Nor does this proposal specify the kind values, which remain processor-dependent. This syntax suggestion is purely illustrative for now: int8_kind, int16_kind, int32_kind, int64_kind real32_kind, real64_kind, real128_kind int_default_kind, real_default_kind, real_double_kind History: Paper 04-240 meeting 167 Submitted 04-407r1 170 Accepted as complete ------------------------------------------------------------------ Number: J3-031 Title: ANDTHEN and ORELSE pseudo-functions Submitted By: J3 WG5 Status: Rejected, May 2005 Development Status: Specification complete Severity Level : 4 References: 04-193, 04-410r1 Basic Functionality: Guarantee short-circuit evaluation of AND and OR operations. Rationale: There has been considerable e-mail discussion of a way to perform short-circuiting of tests, usually to allow writing things simply and to avoid common user errors. Various forms of an .ANDTHEN. operator have been proposed. A canonical example is I > 0 .AND. I < 10 .ANDTHEN. A(I) /= 0 the .ANDTHEN. guarantees that A(I) won't be referenced if I is out of range. Paper 04-390 provides more rational. Much of the discussion has centered on the priority of the new operators. Should they be: highest, lowest, the same or different, or the same as .AND. and .OR.? Reasonably compelling arguments have been made for all of the possibilities. This proposal replaces the operators with functions and thus resolves the priority issue. The functions are called pseudo-functions to emphasize that they are different from normal functions. An alternate name could be "selector functions". They can be used anyplace that an ordinary function can be used, including in declarations, if they follow whatever normal rules apply to that use. The functionality guarantees that the argument expressions will be evaluated in the listed order, left to right, one at a time, and that argument evaluation will stop when the function result can be determined, and that exceptions and side effects won't occur for un-required evaluations. They effectively require short-circuiting. Estimated Impact: 4 on the JKR scale. Detailed Specification: Add two new elemental pseudo-functions ANDTHEN (A1 ,A2 [, A3, ...AN] ) ORELSE (A1 ,A2 [, A3, ...AN] ) Arguments: A1, ...AN Logical, of any kind, they must be conformable The arguments are evaluated in sequence, left to right, one at a time. Evaluation of the arguments stops when ANDTHEN encounters a FALSE value, ORELSE encounters a TRUE value, or when the last argument has been evaluated. The result of the function is the value of the last argument actually evaluated. (This is equivalent to the AND or OR, respectively, of all of the evaluated arguments.) Entities in arguments which are not evaluated need not be defined, present, allocated, evaluatable, etc, nor may the processor generate any side-effects or exceptions from these arguments. Note that for elemental usage, different result elements will usually evaluate different sets of arguments. Examples: IF ( ANDTHEN(I > 0, I<10, A(I) > 0 ) ) A(I) = log(A(I)) WHERE ( ANDTHEN( X > 0.0, log(X) < Tol) ) ... IF ( ANDTHEN( PRESENT(X), X==0) ) Print *, "X must not be zero!" The function can be usefully combined with the "IF" function from paper 04-357r1 Local_value = IF ( ANDTHEN ( present(X), X /= 0.0), X, 1.0) ) REAL :: Temp ( IF ( ANDTHEN (present(x), size(x)>100), size(x), & & 100) ) History: J3/04-390, 04-193, 04-357R1 Paper 04-193 meeting 167 Submitted 04-390 170 04-410r1 170 Accepted as complete ------------------------------------------------------------------ Number: J3-032 Title: FINDLOC Submitted By: J3 WG5 Status: Decision deferred, May 2005 Development Status: For Consideration References: J3/03-106, Public Comment by Jean Vezina Basic Functionality: Intrinsic returns location of first element containing a specified value (which may be .true. or .false.), searching from the first or last element of an array. Rationale: Considered in response to a public comment, this formulation is modeled on the MINLOC/MAXLOC procedures. Rather than propose two procedures, a BACK= is proposed modeled after similar argument to the character search routines INDEX, SCAN, and VERIFY. The BACK= is used to distinguish forward and backward searches, this may result is coding convenience or in more compact code. Estimated Impact: The impact score was 3 on the John Reid scale at 167. Detailed Specification: FINDLOC( ARRAY= , VALUE= [, DIM= s-i-e, BACK= s-l-e, KIND= i-i-e]) may be of any intrinsic TKR. shall be a scalar and shall be == compatible with , or if both are logical. shall be an array. DIM and KIND are defined as per MAXLOC and MINLOC. DIM selects the dimension(s) to be scanned, KIND sets the kind value of the result. BACK is defined as per INDEX, SCAN, and VERIFY. If present with the value of .TRUE., the array search scans backwards from the last element of the array, and the indices returned are those of the last element whose value equals the . Returns the indices of the first element of where the value of an element is equal to the scalar specified by the VALUE argument. If is type logical, the test is .eqv. value. Otherwise, the test is == value. If BACK= is present and the s-l-e evaluates to true, returns the index of the first element whose value is starting with the last element and searching backwards (so it returns the last element overall). Example: given integer, dimension( 3) :: i = [ 3, 5, 5] integer, dimension( 1) :: idx idx = findloc( i, value= 5) assigns [2] to idx. For symmetry, it may be desirable to add a BACK= to MAXLOC and MINLOC. However, this paper does not propose to do so. History: Paper 04-113 meeting 167 Submitted 05-124r3 171 Accepted as complete ------------------------------------------------------------------ Number: J3-033 Title: Document Processor Version Submitted By: J3 WG5 Status: Decision deferred, May 2005 Development Status: For Consideration References: Basic Functionality: Add to iso_fortran_env a processor defined character constant rank-1 array of processor-defined length, containing processor specified version information. Rationale: Many times, after a suspected compiler bug has been detected, the next step is to check a bug database. This lookup needs the compiler's version information to succeed. Today, this comes from a "-V" or "-version" command line option, or some other processor dependent means. Even when the bug is an application error, knowing the compiler version which first detected it is often helpful. Benchmarks and verifications also must document the exact processor used to compile the application. Estimated Impact: The Estimate is 3 on the John Reid scale. Processors would have to make their version strings available via a name in iso_fortran_env. Vendors might actually benefit from more detailed bug reports. Detailed Specification: Add to iso_fortran_env a default character constant rank-1 array named processor_version. This will contain the processor-dependent version information. A Note is added to recognize that a sufficiently clever user may subvert simple implementations of this proposal by "mix-and-match"ing components of a processor. However, such actions are so far beyond the standard that nothing may be done beyond this simple warning. If defined by standard Fortran, it's declaration might appear similar to: character( len= 72), dimension( 3), parameter :: & processor_version = [ 'Acme Fortran 2008 v 8.2a', & 'Acme SuperLinker v 5.6c', & 'Acme RTL v 3.4e' ] A programmer could add: write(*,*) ( trim( processor_version( i), & i = 1, size( processor_version)) to an application to document the processor in use in the application's preconnected output file. Perhaps add a Note detailing that the usefulness of this feature may be subverted by users who mix-and- match components from several releases of a processor. History: Paper 04-137 meeting 167 Submitted 05-123r2 171 Accepted as complete ------------------------------------------------------------------ Number: J3-034 Title: Add MOLD to ALLOCATE Submitted by: J3 WG5 Status: Decision deferred, May 2005 Development Status: For Consideration References: J3/02-274, J3/03-254, J3/04-152 Basic Functionality: A MOLD argument should be added to ALLOCATE similar to the SOURCE argument, which would only give the type of the allocated data, but not the contents. This would allow one to allocate an array of a given type given only a scalar of that type, which is needed to design custom allocators for various dynamic data structures. Rationale: Certain dynamic data-structures strain the memory allocator to a maximum, requesting allocation and deallocation of lots of nodes (i.e., small allocations), while in actuality not really changing the total allocated memory much. To deal with such situations efficiently across a variety of compilers and usage patterns, it is best to include as part of the dynamic data structure a memory "allocator". Such an allocator can be made type-independent by using a scalar mold to give the type of the allocation only, but not the contents. There are other similar situations where it is desired to allocate a new object of unknown dynamic type, and rather then clone the contents of another object, perform default initialization on the newly allocated object. This is very similar to the "new" operator in C++. The current SOURCE in ALLOCATE is not appropriate because it does a clone operation: 1. "source-variable is then assigned to allocate-object by intrinsic assignment for objects whose declared type is the dynamic type of source-variable" and there is also the restriction: 2. "The source-variable shall be a scalar or have the same rank as allocate-object" which means that one cannot allocate a whole array given just a scalar as a type template (mold). The alternative is to use a SELECT TYPE construct, which requires 1. The names of the desired types are accessible, and 2. One must know in advance all desired dynamic types. Objections to these two requirements were the reason to add SOURCE to the Fortran 2003 requirements. Estimated Impact: This feature has a modest impact on both the standard and compilers. This is very simple to incorporate into the standard (Aleks Donev proposed detailed edits earlier). Implementation wise, the only difference with SOURCE is that default initialization needs to be performed on a polymorphic variable, i.e., without knowing the type at compile-time. That is, one must have the run time support to default-initialize a variable given its type descriptor and address. This already needs to be done for polymorphic INTENT(OUT) (see 270:38-41 in draft 03-007r2) variables, so the run-time support neccessary for it needs to be in compilers already. Detailed Specification: Add a MOLD keyword to the ALLOCATE statement. The allocated object shall have the same dynamic type as the object specified by MOLD. Unlike SOURCE, use default initialization instead of intrinsic assignment for the value of the allocated object. Require the mold to be a scalar even if the allocation is for an array. MOLD and SOURCE shall not both appear. Therefore: CLASS(base_type), POINTER :: var1, var2 TYPE, EXTENDS(base_type) :: dynamic_type_of_var2 END TYPE TYPE (dynamic_type_of_var2), TARGET :: var3 var2 => var3 ALLOCATE(var1, MOLD=var2) should be equivalent to: SELECT TYPE ( var2 ) ... TYPE IS ( dynamic_type_of_var2 ) ALLOCATE(dynamic_type_of_var2::var1) END SELECT History: Paper 04-152 meeting 167 Submitted 05-157 171 Accepted as complete ------------------------------------------------------------------ Number: J3-035 Title: Beginning a source line with a semicolon Submitted By: J3 WG5 Status: Decision deferred, May 2005 Development Status: For consideration Basic Functionality: Remove the restriction against beginning a source line with a semicolon. Rationale: This restriction is stated in 3.3.1.3 (for free source form) and 3.3.2.4 (for fixed source form) of Fortran 2003. This restriction was not in the original F90, but was added by F90 corrigendum 3. It remained in F95. It is an unnecessary restriction: removing it simplies the standard. Estimated Impact: It is row #39 in spreadsheet 05-145. It received a Hate-Love vote of 0-0-13-2 and was judged an impact of 3 on the Reid scale. Detailed Specification: Remove the restriction against beginning a source line with a semicolon as stated in section 3.3.1.3 (for free source form) and 3.3.2.4 (for fixed source form) of Fortran 2003. History: Paper 04-282 meeting 168 Submitted 05-161 171 Accepted as complete ------------------------------------------------------------------ Number: J3-036 Title: USE, EXCEPT: Submitted By: J3 WG5 Status: Rejected, May 2005 Development Status: For Consideration References: J3/03-106, J3/04-114 Basic Functionality: A syntax to list names not to have use association when using a module. Rationale: When using a module with many public names, a few may be unwanted. Specifying those few is easier than naming the many wanted names, and less ugly than fanciful renames. Estimated Impact: 4 on the John Reid scale at 167 Detailed Specification: Add a clause to the USE statement specifying names not available via use association. If EXCEPT: is present, ONLY must not be present, and there can be no renames (in the ). (It makes no sense to say "don't use this name, and call it 'foo'".) If any USE statement for a given module in a scoping unit has an EXCEPT, all use statements for that module in that scoping unit must have an EXCEPT clause. The effective EXCEPT list is the concatenation of all the EXCEPT lists naming the given module. History: Paper 03-106 meeting ??? ??? 04-114 167 Submitted 05-135r2 171 Accepted as complete ------------------------------------------------------------------ Number: J3-037 Title: Pointers and Targets Submitted By: J3 WG5 Status: Rejected, May 2005 Development Status: For Consideration References: 04-131 Basic Functionality: Improve aliasing analysis by indicating pointers to targets and targets of pointers. Rationale: Compilers must generate code which allows data to be kept in the fastest memory closest to functional units for highly optimized code sequences. Conservative assumptions regarding aliasing prevent it, providing information to allow more aggressive analysis allows it. Estimated Impact: Compilers would have to recognize lists in two new places and they should be able to detect textual falsehoods, but they need not use this information when generating code. High quality implementations will do so. A forward reference must be accepted, because both pointer and target cannot be declared in the same statement. If no other accepted feature proposal provides for such forwared references, this proposal implicitly contains a proposal to allow such forward references. Detailed Specification: Allow the programmer to list the targets of pointers and the pointers to targets, as follows: Modify the TARGET declaration syntax by optionally placing a parenthesized list of pointers after it. For example: real, target( pa) :: ta This indicates that only pointer pa will be associated with target ta. The variable pa shall have the pointer attribute and have characteristics such that it could be associated with ta. If pa is declared subsequently, that declaration shall confirm the required characteristics. Modify the POINTER declaration syntax analogously: real, pointer( ta) :: pa This indicates that pointer pa will only be associated with target ta. The variable ta shall have the target attribute and have characteristics such that it is a valid target for pa. If ta is declared subsequently, that declaration shall confirm the required characteristics. A set of declarations with pointer or target lists shall not be inconsistent. Note that for the two example declarations above, one (pa or ta) must contain a forward reference. The circumstances where one declaration of the two above is allowed to be in a different compilation unit should be resolved by J3. The POINTER and TARGET statements are modified to allow the same new syntax as the corresponding attribute specifiers. In general, TARGET [ ( ) ] and POINTER [ ( ) ] Examples: ! targets of a pointer real, pointer( t1, t2) :: ptr real, target :: t1, t2 real, target :: tgt ! accepted: ptr => t2 ! not accepted: ptr => tgt ! ----------------------------- ! pointer to a target real, pointer :: ptr real, target( ptr) :: t1, t2 real, target :: tgt ! accepted: ptr => t2 ! not accepted: ptr => tgt ! ----------------------------- ! symmetrically constrained declarations real, pointer( t1, t2) :: ptr real, target( ptr) :: t1, t2 History: Paper 04-131 meeting 167 Submitted 05-160 171 Accepted as completed ------------------------------------------------------------------ Number: J3-038 Title: C libm functions as Fortran intrinsics Submitted By: J3 WG5 Status: Accepted as second priority item, May 2005 Development Status: Specification, edits complete References: C99 7.12 Mathematics page 211 et seq. Unix Programmer's Manual, Volume 2, System calls and Library Routines (3m) Basic Functionality: Add the Bessel functions, hypot, and error functions to the Fortran intrinsic function set for real arguments. Rationale: Fortran is mainly used for numerical problems, supplying mathematical functions of proven utility will assist Fortran is continuing as the premier mathematical programming language in the world today. Estimated Impact: The estimated impact at 167 was 4 on the John Reid scale. These are proposed intrinsic functions, no other feature is affected. Impact on vendors is minimal, as most vendors support these functions anyway for their C/C++ compilers. Detailed Specification: Add subsections to Section 13 detailing the Fortran names for these procedures. (The C names should not be used due to the common usage, in Fortran, of names such as j0 etc.) The functions are (the C names): Bessel functions (j0, j1, jn, y0, y1, yn) Error Functions (erf, erfc) Hypotenuse (hypot) Gamma and log gamma (tgamma, lgamma) The detailed mathematical specification of these procedures is given in the references above. The intention is to allow the vendor to use the procedure supplied by libm, so the exact specification is left to libm, which is most likely what the applications programmer wants. Since Fortran does not support the concept of external variables, the signgam variable of lgamma may be defined as an optional intent(out) argument. Edits would include adding to the list in 13.5.2: BESSEL_J0 BESSEL_J1 BESSEL_JN BESSEL_Y0 BESSEL_Y1 BESSEL_YN COMP_ERROR_FUNC ERROR_FUNC GAMMA_FUNC HYPOT LOG_GAMMA_FUNC History: Paper 04-246 meeting 167 Submitted 05-132r2 171 Accepted as complete ------------------------------------------------------------------ Number: J3-039 Title: Rank > 7 Submitted By: J3 WG5 Status: Accepted as first priority item, May 2005 Development Status: Specification, edits complete Basic Functionality: Relax the restriction on the maximum rank of an array. Rationale: The limit of seven dimensions was set when Fortran was first published in 1957 and has never been changed. Requests for increasing this limit have been made by international bodies for years. See the previous WG5 repository N1189, Numbers 24 (from the Russian Fortran Working Group) and Number 24a (from X3J3, JOR 95-004r1, item 067). Estimated Impact: (Listed as 4 on the JKR scale) The standard would require changes in at least four places. This will not impact any existing code. Any other impact should be apparent only when arrays of rank greater than seven are declared and referenced. Detailed Specification: Increase the maximum permitted rank for arrays. Changes would be needed to the following places in F2003: [18:5] An array may have up to seven dimensions ... [78:4] C541 (R510) The maximum rank is seven. (repeated in Annex D, page 517) [108:6+] Table 6.1 [353:19] The rank of SOURCE shall be less than 7. History: Aug 95, J3 Meeting 134: Change max 255 to > 7 approved by US TAG for F2000 as medium priority WG5-N1189 (20 June 1996) Paper 05-144r2 meeting 171 Accepted as complete ------------------------------------------------------------------ Number: J3-040 Title: Compute if actual argument is present Submitted By: J3 WG5 Status: Rejected, May 2005 Development Status: For consideration. Basic Functionality: Provide a mechanism to compute whether an actual argument is present Rationale: If the presence of an argument controls whether a calculation is performed, and if the desire to perform the calculation is determined by the results of other calculations, one needs to be able to compute whether the argument is present or absent. In Fortran 2003, the way to do this is with an IF construct. But with n arguments, one needs a 2^n-way if-elseif...-else-endif construct with a different one of the 2^n possible combinations of present actual arguments in each branch. It would be more convenient if one could use a syntactic form for an actual argument to calculate whether it is present. It is important that the desired entity, not the value of it, is the actual argument. Otherwise, it would not be useful where the associated dummy argument does not have INTENT(IN). Estimated Impact: This is part of the proposal in J3 paper 04-393, whose antecedent was 04-357r1. At J3 meeting 169, the proposal in 04-357r1 was judged to be at 4 on the JKR scale. Surely this proposal, being only part of the previous one, is not larger. Detailed Specification: Provide a mechanism to compute whether an actual argument is present. If the condition specifies that the actual argument is present, to be useful in the case the desired entity is not an expression, or is a procedure argument, it, rather than the value of it, must become the actual argument. No matter what syntax is used, if there is no special description it cannot be called a function or operation, because the result would be a value separate from the desired entity itself. If the condition specifies that the actual argument is absent, neither the entity that would otherwise become the actual argument, nor any expressions within it, shall be evaluated. That the condition specifies the entity is considered to be absent might be a proxy for the nonexistence of values necessary for these evaluations. Examples: Several syntaxes are possible. Two under consideration are similar to a function reference, and similar to an operator. CALL MY_SUB ( A, IF(PRESENT(B),B(:,I)) ) or CALL MY_SUB ( A, PRESENT(B) ? B(:,I) ) History: Paper 04-393r1 meeting 170 Submitted 05-103r1 171 Accepted as complete ------------------------------------------------------------------ Number: J3-041 Title: Interoperability of pointers, allocatables, and assumed-shape arrays Submitted By: J3 WG5 Status: Accepted as second priority item, May 2005 Development Status: For consideration Reference: 04-371r2 Basic Functionality: Extensions to C Interop that allow arguments that are pointers, allocatables, and assumed-shape arrays to be interoperable. Rationale: C interoperability provides a mechanism to share array data between Fortran and C. However, even with C interop, it is still necessary for users to implement a translation layer between C and Fortran assumed-shape array data structures. Under some circumstances, it may even be necessary to make temporary copies of array data in this translation layer. In the translation layer, for each array-valued parameter in a BIND(C) procedure, a user needs to pass the address of the array as well as each value of the array shape as integer procedure parameters. For BIND(C) procedures taking many array arguments, the resulting argument list can be exceptionally long. In addition, data marshaling in the translation layer can be a performance hit. Estimated Impact: Small impact for the standard and probably small to moderate impact for the processors. Detailed Specification: The processor will be required to supply, for each companion C processor, a C header file and C functions (or macros) implementing the C prototypes shown below. In C, descriptors for assumed-shape, allocatable, and Fortran pointer objects are represented by opaque types. The C functions specified by these prototypes allow C programmers to create and destroy memory for descriptors, functions to get and set parameters in a descriptor, and functions to allocate and deallocate the memory described by the descriptors. Separate opaque types are defined for the assumed-shape, allocatable, and pointer cases. Type and function names containing _ASSUMED_ are used with assumed-shape arguments, names containing _ALLOC_ are used with allocatable arguments, and names containing _POINTER_ are used with pointer arguments. The rank may be specified as 0 for allocatable and pointer descriptors, in which case the corresponding Fortran object shall be a scalar. If the rank is 0, the pointers to the shape and stride arrays in the same reference are not used and may have any value. If the base_addr parameter in the FDesc_Alloc_Create or FDesc_Alloc_Reset functions is NULL, the resulting descriptor represents an unallocated object. If the base_addr parameter in the FDesc_Pointer_Create or FDesc_Pointer_Reset is NULL, the resulting descriptor represents an unassociated pointer. A C function calling a Fortran procedure with the BIND(C) attribute will pass a pointer to an array descriptor as the actual argument corresponding to an assumed-shape, allocatable, or pointer dummy argument. Depending on the details of the processor's Fortran descriptors, the procedure may be required to merge additional information into the descriptor based on the declaration of the dummy argument, or to create a local representation based on the information in the descriptor. If the dummy argument is deallocated, allocated, or has its pointer association status changed in the procedure, the descriptor shall be modified to reflect the new state of the argument. A C function that is called from a Fortran procedure will be passed a pointer to a descriptor of the type appropriate for the corresponding dummy argument in the interface for the called function. Such an argument must have interoperable type and type parameters. /** * FDesc.h - name of include file declaring descriptor typedefs * and prototypes */ /** * * An opaque type for the size of extents. * * F_extent_t * */ /** * Opaque descriptor types. * * FDesc_Alloc_t * FDesc_Pointer_t * FDesc_Assumed_t * */ /** * Allocation, deallocation and reset routines for descriptors */ /** * Create a descriptor and initialize its data. * * Memory for the descriptor must be freed by a subsequent call to * FDesc_Alloc_Destroy, FDesc_Pointer_Destroy, or * FDesc_Assumed_Destroy. * * @param fdesc contains address of descriptor on return. * @param base_addr the base address of the array or scalar object. * @param elem_size the size of an array element or scalar object * (in bytes). * @param rank the rank of the array; 0 if object is scalar. * @param shape array[rank] containing the array shape. * @param stride array[rank] containing the distance between * successive array elements for each dimension * (in bytes). * @return 0 if successful (nonzero on error). */ int FDesc_Alloc_Create(FDesc_Alloc_t * restrict fdesc, void * restrict base_addr, size_t elem_size, unsigned int rank, const F_extent_t shape[restrict], const size_t stride[restrict] ); int FDesc_Pointer_Create(FDesc_Pointer_t * restrict fdesc, void * base_addr, size_t elem_size, unsigned int rank, const F_extent_t shape[restrict], const size_t stride[restrict] ); int FDesc_Assumed_Create(FDesc_Assumed_t * restrict fdesc, void * base_addr, size_t elem_size, unsigned int rank; const F_extent_t shape[restrict] ); /** * Set the elements of a descriptor. * * @param fdesc address of descriptor. * @param base_addr the base address of the array or scalar object. * @param shape array[rank] containing the array shape (in * elements). * If base_addr is NULL, the contents of shape are * ignored and the descriptor shape values are * set to 0. * @param stride array[rank] containing the distance between * successive array elements for each dimension * (in bytes). * If base_addr is NULL, the contents of stride are * ignored and the descriptor stride values are * set to 0. * @return 0 if successful (nonzero on error). */ int FDesc_Alloc_Reset(FDesc_Alloc_t * restrict fdesc, void * restrict base_addr, const F_extent_t shape[restrict], const size_t stride[restrict] ); int FDesc_Pointer_Reset(FDesc_Pointer_t * restrict fdesc, void * base_addr, const F_extent_t shape[restrict], const size_t stride[restrict] ); /** * Frees memory for a descriptor. * * @param fdesc address of a descriptor. * @return 0 if successful (nonzero on error). */ int FDesc_Alloc_Destroy(FDesc_Alloc_t * restrict fdesc); int FDesc_Pointer_Destroy(FDesc_Pointer_t * restrict fdesc); int FDesc_Assumed_Destroy(FDesc_Assumed_t * restrict fdesc); /** * Routines to allocate and deallocate array or scalar object memory */ /** * Returns a value appropriate for use as base_addr in Create and * and Reset routines. * * @param size amount of memory to allocate, in bytes. * @return pointer to allocated memory, or NULL if the * memory allocation fails. */ void * FDesc_Alloc_Allocate(size_t size); void * FDesc_Pointer_Allocate(size_t size); void * FDesc_Assumed_Allocate(size_t size); /** * Frees memory previously allocated with FDesc_Alloc_Allocate, * FDesc_Pointer_Allocate, or FDesc_Assumed_Allocate. * FDesc_Alloc_Deallocate and FDesc_Pointer_Deallocate may be * used to deallocate memory previously allocated by a Fortran * procedure. * * @param fdesc address of descriptor. The base_addr in the * descriptor is set to NULL on return. * @return 0 is successful (nonzero on error). */ int FDesc_Alloc_Deallocate(FDesc_Alloc_t * restrict fdesc); int FDesc_Pointer_Deallocate(FDesc_Pointer_t * restrict fdesc); int FDesc_Assumed_Deallocate(FDesc_Assumed_t * restrict fdesc); /** * Accessors */ /** Returns true if the pointer is associated (false otherwise). */ _Bool FDesc_Associated(FDesc_Pointer_t fdesc); /** Returns true if the object is allocated (false otherwise). */ _Bool FDesc_Allocated(FDesc_Alloc_t fdesc); /** Returns the rank of the array described by a descriptor */ int FDesc_Alloc_Rank(FDesc_Alloc_t fdesc); int FDesc_Pointer_Rank(FDesc_Pointer_t fdesc); int FDesc_Assumed_Rank(FDesc_Assumed_t fdesc); /** * Return the address, shape, and stride information in a descriptor. * * @param fdesc the descriptor. * @param base_addr contains the address of the array or scalar * object on return. * @param shape array[rank] containing the array shape on return * (in elements). If the rank is 0, shape is not * returned. * @param stride array[rank] containing the distance between * successive array elements for each dimension * (in bytes) on return. * If rank is 0, stride is not returned. * @return 0 if successful (nonzero on error). */ int FDesc_Alloc_Get(FDesc_Alloc_t fdesc, void ** restrict base_addr, F_extent_t shape[restrict], size_t stride[restrict] ); int FDesc_Pointer_Get(FDesc_Pointer_t fdesc, void ** base_addr, F_extent_t shape[restrict], size_t stride[restrict] ); int FDesc_Assumed_Get(FDesc_Assumed_t fdesc, void ** base_addr, F_extent_t shape[restrict], size_t stride[restrict] ); /** End of FDesc.h */ History: Paper 04-371r2 meeting 169 Submitted 05-159 171 Accepted as complete ------------------------------------------------------------------ Number: J3-042 Title: Interoperability of optional arguments Submitted By: J3 WG5 Status: Accepted as second priority item, May 2005 Development Status: For consideration Basic Functionality: Extension to C Interop that allows optional arguments to be interoperable. Rationale: If C functions have a mechanism to indicate and detect missing optional arguments, the class of Fortran subprograms that interoperate with C would be significantly expanded. Estimated Impact: Small impact for the standard and probably small to moderate impact for the processors. Detailed Specification: The VALUE attribute is not allowed for optional dummy arguments in a BIND(C) interface. A C function specifies a missing actual argument in a function reference by passing a NULL data pointer as the argument value if the corresponding dummy argument is a data object, or a NULL procedure pointer as the argument value if the corresponding dummy argument is a procedure. If the function being referenced is a Fortran procedure, the corresponding dummy argument must have the OPTIONAL attribute, and the procedure must have the BIND(C) attribute. A Fortran subprogram with the BIND(C) attribute specifies a missing actual argument in a subroutine call or function reference by passing C_NULL_PTR by value for a missing data argument and C_NULL_FUNPTR by value for a missing procedure argument. The OPTIONAL attribute must be specified for the corresponding dummy argument. The C function can detect a missing argument by comparing its value to NULL. History: Paper 04-373 meeting 169 Submitted 171 Accepted as complete ------------------------------------------------------------------ Number: J3-043 Title: contiguous pointers Submitted By: J3 WG5 Status: Accepted as first priority item after modification as per J3/05-186, May 2005 Development Status: Specification, syntax, edits complete References: J3/04-132 [J3/05/149r2 added by modification] Basic Functionality: Provide a method to indicate that the target of a pointer or an actual argument is contiguous. Rationale: Many unnecessary operations happen because compilers cannot determine that a data item occupies contiguous memory. For example, contiguous memory is needed to pass an array to a procedure with an implicit interface. Certain optimizations are possible if the compiler knows that the memory stride for the left-most subscript is 1, or if a whole array occupies a contiguous memory block. Thus, the mere use of pointers often results in substantially suboptimal code. If the compiler knew that the pointer was constrained to point to contiguous memory, very much better code could be generated. Similar optimization problems exist for assumed-shape dummy arguments. Estimated Impact: The effort was estimated as 5 on the John Reid scale at M167. Detailed Specification: Original: Provide a declaration attribute, CONTIGUOUS, that specifies that the pointer being declared will only be associated with a target occupying a storage sequence or that an assumed-shape dummy argument is associated with a contiguous actual argument. For example, real, pointer, contiguous :: sptr(:) real, contiguous, dimension(:,:) :: d If the variable is a dummy argument with the pointer attribute, the target of the associated actual argument shall be a storage sequence. If the variable is an assumed-shape array, the associated actual argument shall be a storage sequence or a pointer associated with a target that is a storage sequence. A corresponding CONTIGUOUS :: statement is also provided. After modification (J3/05-186): Provide a declaration attribute, CONTIGUOUS, that specifies that the pointer being declared will only be associated with a target occupying a storage sequence or that the elements of an assumed-shape dummy argument occupy a storage sequence. The processor may need to make a contiguous copy of an actual argument associated with a dummy argument with the contiguous attribute. For example, real, pointer, contiguous :: sptr(:) real, contiguous, dimension(:,:) :: d A corresponding CONTIGUOUS :: statement is also provided. An intrinsic function, IS_CONTIGUOUS(A), is also provided. The argument is an array or array section. The result is .true. if the argument occupies a storage sequence, and .false. otherwise. History: Paper 04-132 meeting 167 Submitted 05-149r2 171 Accepted as complete ------------------------------------------------------------------ Number: J3-044 Title: New Intents Submitted By: J3 WG5 Status: Accepted as first priority item, May 2005 Development Status: For Consideration References: J3/04-135 Basic Functionality: Add a new intent for dummy arguments: INTENT(SCRATCH) specifies that the dummy argument is undefined on entry and return. The argument may be used for scratch work space only. Compilers may be able to optimize this argument aggressively. Rationale: Many older Fortran programs have dummy arguments which are used for scratch work space only. Any use of existing argument intents gives wrong information to the compiler. Also, in the process of converting scratch work arrays in common blocks to allocatable dummy arguments, there is no proper intent for 'scratch' variables. An optimizing compiler could scalarize a dummy argument array known to be scratch. Also, final values of the dummy argument do not need to be stored. Estimated Impact: The impact was rated as 5 on the John Reid scale at 167. Lowered to 4 at meeting 171. Detailed Specification: A new INTENT(SCRATCH) attribute is proposed. The actual argument associated with a dummy argument with the INTENT(SCRATCH) attribute shall be definable. The dummy argument is undefined upon entry to the procedure and becomes undefined upon exit from the procedure. History: Paper 04-135 meeting 167 Submitted 05-147r2 171 Accepted as complete ------------------------------------------------------------------ Number: J3-045 Title: Same shape arrays Submitted By: J3 WG5 Status: Rejected, May 2005 Development Status: For Consideration References: J3/04-136 Basic Functionality: Provide syntax to specify that an array has the same shape and bounds as a specified array. Rationale: Compilers will be able to generate more efficient code when they can assume that several arrays all have the same shape and bounds. It is also a convenience to programmers, especially for the declaration of automatic arrays with the same shape and bounds as a dummy argument. Estimated Impact: The effort was estimated as 5 on the John Reid scale at 167. Detailed Specification: A new declaration attribute, BOUNDS(), is provided to specify that the variable being declared has the same shape and bounds as the specified . If is an assumed-shape array, the variable is an assumed-shape array if it is a dummy argument; otherwise the variable is an explicit-shape array. If is a deferred-shape array, the variable is a deferred-shape array if it is a dummy argument or has the pointer or allocatable attributes; otherwise the variable is an explicit-shape array. If is an explicit-shape array, the variable is an explicit-shape array. If the variable and are both assumed-shape dummy arguments, the associated actual arguments shall have the same shape. If the variable and are both deferred-shape dummy arguments, the associated actual arguments shall have the same shape and bounds. The bounds of shall be previously specified in the same scoping unit, or shall be accessible by USE or host association. If the is a pointer, it shall be associated at entry to the scoping unit containing the declaration. If the is allocatable, it shall be allocated at entry to the scoping unit containing the declaration. The bounds of the variable being declared are not affected by subsequent changes to the bounds of . A corresponding BOUNDS() :: statement is also supplied. For example, real, dimension(:,:,:) :: a real, bounds(a) :: b ! instead of real,dimension(:,:,:) :: b History: Paper 04-136 meeting 167 Submitted 05-148r1 171 Accepted as complete ------------------------------------------------------------------ Number: J3-046 Title: DO CONCURRENT Construct Submitted By: J3 WG5 Status: Accepted as first priority item, May 2005 Development Status: Specification, syntax, edits complete References: J3/04-243 Basic Functionality: The DO CONCURRENT construct is a new form of the block DO construct using loop control syntax like that of FORALL. It would allow the iterations of the loop to be executed in any order. Restrictions on the statements in the loop block are required, but the restrictions are significantly fewer than for FORALL constructs. Rationale: The performance of most modern processors is enhanced, sometimes significantly, if the number of memory references is reduced. This is typically accomplished by keeping more of the program data in processor registers, especially during iterations of a loop. Data from different loop iterations may be held in independent parts of a multi-word register (vectorization), in disjoint subsets of a single register set (loop unrolling), or in the register sets of several different processors or processor cores of a multi-threaded processor (parallel execution). Many modern computer systems can already take advantage of all of these optimization methods, and trends in computer system architecture suggest these optimization techniques will be even more important in the future. The DO CONCURRENT construct is designed to allow compilers to better use these optimizations. These optimizations rely on the values contained in registers being the same as the associated values in memory when the corresponding variables are referenced during execution of the construct. This is the case if there is no associated memory value during execution of the construct, or if the nature of cross iteration data dependencies is properly limited. Compared to the FORALL construct, the DO CONCURRENT construct allows a much larger class of statements within the block, including calls to pure subroutines and some branches. DO CONCURRENT constructs also avoid the iteration space temporaries that FORALL requires in cases where the compiler cannot prove there are no cross iteration dependencies. If there really are dependencies, FORALL may be the better option, but in a large number of cases, there are no actual dependencies and DO CONCURRENT will provide much better performance. The DO CONCURRENT construct provides a way for the programmer to specify that the aggressive optimizations described above are allowed. It is cleaner and more portable than the current method of using directives that have difference spellings and meanings among vendors. Estimated Impact: Specifications of the new syntax and restrictions on the statements in the construct block are needed in section 8.1.6. Additions in section 16 to subsections on variable definition and undefinition, and pointer association status are also needed. Implementation in compilers should be simple, as many compilers already support similar features through directives. At a minimum, a compiler could convert the construct to a set of ordinary DO loops, possibly with an added IF test. The original proposal in 04-243 was rated as an impact of 5 on the JKR scale. This proposal is somewhat simpler than the original because it leverages the existing block DO construct. Detailed Specification: The syntax for DO CONCURRENT specifies a new for the existing that uses the FORALL header syntax: [,] CONCURRENT The scope rules for an in the are the same as in a FORALL construct (7.4.4.1). The values of the index variables for the iterations of the construct are determined by the rules for the index variables of the FORALL construct (7.4.4.2.1 and 7.4.4.2.2). The number of distinct index value tuples is the iteration count for the construct. The order in which the iterations are executed is indeterminant. A statement in the loop range shall not cause a branch out of the loop range. The loop range shall not contain an EXIT statement that would cause the DO CONCURRENT construct to terminate. A variable that is referenced in an iteration of a DO CONCURRENT construct shall either be previously defined during that iteration, or shall not be defined during any other iteration. A variable that is defined in more than one iteration becomes undefined when execution of the construct completes. A pointer that is referenced in an iteration of a DO CONCURRENT construct either shall be previously pointer associated during that iteration, or shall not become pointer associated in the loop range. A pointer that is pointer associated in more than one iteration has a processor dependent association status when the execution of the construct completes. An allocatable object that is allocated in more than one iteration of a DO CONCURRENT construct shall be subsequently deallocated during the same iteration in which it was allocated. An object that is allocated or deallocated in only one iteration of a concurrent shall not be deallocated, allocated, referenced, or defined in a different iteration. An input/output statement in a DO CONCURRENT construct shall not write data to a file record or position in one iteration and read from the same record or position in a different iteration. Procedures referenced in the loop range of a DO CONCURRENT construct shall be PURE. If the IEEE_EXCEPTIONS intrinsic module is accessible, references to the IEEE_GET_FLAG, IEEE_SET_HALTING_MODE, and IEEE_GET_HALTING_MODE subroutines shall not appear in the loop range. Note: The restrictions on referencing variables defined in an iteration apply to any procedure invoked by the loop. Note 12.44 in section 12.6 (Pure procedures) should be updated to include the DO CONCURRENT construct as well as the FORALL construct. History: Paper 04-243 meeting 167 Submitted 05-133r2 171 Accepted as complete ------------------------------------------------------------------ Number: J3-047 Title: TYPELESS objects in Fortran (subsequently changed to BITS) Submitted By: J3 WG5 Status: Accepted as second priority item after modification as per J3/05-188, May 2005 Development Status: Specification, syntax complete References: 03-278, 04-244 Basic Functionality: Objects declared as TYPELESS have kind and rank attributes, but are treated as only a sequence of bits, without the higher abstractions associated with the traditional Fortran intrinsic types. A method for declaring objects as TYPELESS is provided as well as rules on how such objects interact with existing Fortran objects. Associated intrinsic procedures are also provided. Rationale: Fortran currently lacks support for variables that represent a sequence of bits independent of the interpretations imposed by the traditional numeric, logical, and character data types. Various features have been added to Fortran to facilitate handling sequences of bits by overloading the INTEGER data type, and through vendor extensions. This has lead to limitations in the usefulness of these features as well as awkward wording in the Fortran standard text. Adding a new intrinsic type specifier, TYPELESS, would simplify and enhance the use of Fortran for certain types of non-numeric problems, such as pattern matching, searching and sorting, and low level bit manipulation, as well as allowing for more clarity in the text of the standard. TYPELESS also provides a way to standardize several common Fortran language extensions, and provides a rational method for dealing with BOZ constants. Estimated Impact: Several edits to the standard would be required to incorporate this feature, though each would be straightforward. Implementation of the feature in compilers should be technically simple. It is rated as a 7 on the JKR scale. Detailed Specification: See j3/05-188 and j3/05-274r3. History: Paper 03-278r1 meeting 166 Initial proposal 04-244 167 Updated proposal 169 Spreadsheet version 05-150r1 171 Accepted as complete ------------------------------------------------------------------ Number: J3-048 Title: Write CSV files Using LDIO Submitted By: J3 WG5 Status: Accepted as second priority item, May 2005 Development Status: Specification, syntax, edits complete References: 04-007 10.9 Basic Functionality: Provide a quick and easy way to write files using the CSV (Comma Separated Value) format. Rationale: CSV files (a/k/a Comma Separated Value) files are used by spreadsheets and "higher level math" programs such as Mathematica, MATLAB and Maple. These programs provide easy access to graphics and other mathematically oriented amenities. List directed input treats the comma as a separator, but the separator is optionally blank or comma on output. If the separator is blank, one or more blanks may be between values. A way to make the optional separator a comma allows an easy way to write CSV files, providing easy communications to spreadsheet programs and other higher level math programs with built-in graphics, algebraic manipulation, and other amenities useful with numeric programs, but absent in standard Fortran. CSV files are formatted, the simplest format from the user's perspective is List Directed. So modify LDIO to serve CSV. Estimated Impact: Rather minor, the RTL must already reckon where to place a separator in LDIO output, and must already recognize comma on LDIO input. Detailed Specification: The idea is to modify list directed output as little as possible to gain connectivity from Fortran programs to desktop applications via CSV format. The proposed solution is: Add a new ACCESS form, ACCESS='CSV' which on output (and has no effect on input) 1. Implies ACCESS='STREAM', and 2. When list directed, requires that the processor not print the "r*" form of repeated values, and 3. When listed directed, disallows blanks as separator (which means comma or semicolon is used as per decimal mode), and 4. When listed directed, allows blanks on either side of the separator as at present, and 5. When listed directed, disallows new records being created (so one write gives one record), and 6. Allows explicit formats to be used as needed. History: Paper 05-108 meeting 171 Submitted 05-108r1 171 Accepted as complete ------------------------------------------------------------------ Number: J3-049 Title: Embed a decision within an expression Submitted By: J3 WG5 Status: Rejected, May 2005 Development Status: For consideration Reference: 03-258r1, section 2.8.1; 04-192, 04-357r1 04-393 Basic Functionality: Provide a mechanism to embed a decision within an expression Rationale If one needs to embed one of several values within an expression, depending upon a condition, the available methods are o Nearly duplicate the statement containing the expression with a different entity within the different instances and select between them using the condition, o Copy one of the values into a temporary variable depending upon the condition and use that temporary variable within the expression, or o Associate a pointer with one of the variables depending on the condition --- if the entities to be selected are variables. In the first case, assuming m alternatives for each of n entities within the statement, m^n instances of the statement are needed. In the second case, the program must endure the expenses of an auxiliary variable and the time to copy it, both of which could be substantial in the array case. In the third case, which only works if the values are variables, the variables have to have the pointer or target attribute, which could have negative implications for optimization. The same considerations apply if one needs to associate one of several entities as an actual argument. It's even worse in the case of using a temporary variable if the associated dummy argument does not have INTENT(IN), because one needs to do the selection and copying twice. It would be useful to be able to embed a decision within an expression. This would avoid all of the problems outlined above. In the case of an actual argument or a target in a pointer assignment, it would be useful to allow procedures or procedure pointers to be the alternative entities. Estimated Impact: This is part of the proposal in J3 paper 04-393, whose antecedent was 04-357r1. At J3 meeting 169, the proposal in 04-357r1 was judged to be at 4 on the JKR scale. Surely this proposal, being only part of the previous one, is not larger. Detailed Specification: Provide a mechanism, called here a "conditional form", to embed a decision within an expression. The syntax shall provide for a condition and two alternative entities. If an actual argument is a conditional form, and the alternatives are either variables or procedures, to be useful the selected entity itself, rather than the value of it, must become the actual argument. Indeed, in the case of an argument that is a procedure, it does not have a value. No matter what syntax is used, if there is no special description it cannot be called a function reference or an operation, because the result would be a value separate from the desired entity itself. One might think that it would be acceptable to call it a function reference or operation that returns a pointer associated with the appropriate alternative entity, but that won't work either, because of the absurd outcome of interp F95/74. That would also require the alternatives to have the target attribute, which would have negative implications for optimization. Maybe a new term that doesn't carry the baggage of "pointer" or "target", such as "referent", could be used to describe the result, allowing the form to be called a function reference or an operation. That seems like a lot of work to invest for one purpose. It is important that the alternative that is not selected, and all expressions within it, are not evaluated. The condition that selects between the alternatives may be a proxy indicating the nonexistence of values necessary for these evaluations. If one of the alternative entities has the pointer attribute and the other does not, the one that does not shall have the target attribute, and the result has the target attribute. If the alternative that has the pointer attribute is selected, the result is its target. Otherwise, the alternative entities shall have the same characteristics. If one of them is the NULL intrinsic without an argument, the result characteristics are inferred from the other. If they are both the NULL intrinsic without an argument, the result characteristics are inferred from the context of the appearance of the conditional form, exactly as would be the case if the NULL intrinsic had appeared on its own instead. Examples: Several syntaxes are possible. Two under consideration are similar to a function reference, and similar to an operator. A = B + IF ( X > 0.0, SQRT(X), 0.0 ) or A = B + X > 0.0 ? SQRT(X) : 0.0 History: Paper 04-192 meeting 167 Submitted 04-357r1 169 Kicked around 04-393 170 Kicked around some more 05-104r1 171 Accepted as complete ------------------------------------------------------------------ Number: RU-001 Title: Remove the restriction on the maximum rank of arrays (or increase a maximum limit on the number of array dimensions). Submitted by: Russian Federation (GOST R) WG5 Status: Accepted as first priority and merged with item J3-039, May 2005 Severity Level: 3 References: WG5-N1189, item 24 (WG5-N919). Basic Functionality: The rank of arrays may be arbitrary, but it must not be less than seven for the sake of portability. Rationale: Some applications require more than seven dimensions. Also this is useful for regularization of Fortran features. Estimated Impact: No effect on existing programs. Detailed Specification: History: Proposed for F95 by Russian Fortran WG in 1991. ------------------------------------------------------------------ Number: RU-002 Title: Extend the semantics of the EXIT statement Submitted by: Russian Federation (GOST R) WG5 Status: Accepted as second priority item and merged with J3-024, May 2005 Severity Level: 3 References: WG5-N1189, item 25 (WG5-N919). Basic Functionality: Extend the semantics of the EXIT statement to allow its use for exit from any control construct. Rationale: This is useful for a more structured style and for regularization of Fortran features. Estimated Impact: No effect on existing programs. Requires very little change in existing processors. Detailed Specification: History: Proposed for F95 by Russian Fortran WG in 1991. ------------------------------------------------------------------ Number: RU-003 Title: Extend the obsolescent features list Submitted By: Russian Federation (GOST R) WG5 Status: Accepted as first priority item after modification as per N1638, May 2005 Development Status: Specification, edits complete Severity Level: 4 References: WG5-N1102 Basic Functionality: Original Proposal: Extend the obsolescent features list with following elements: the old forms for the relational operators, storage association, assumed-size arrays, DOUBLE PRECISION statement, ENTRY statement, BLOCK DATA subprogram, INCLUDE line, etc. Modified to read (in N1638): 1. Move statement functions from the obsolescent feature list to the deleted feature list. 2. Make ENTRY statements obsolescent. Rationale: Estimated Impact: Additions to the Annex B. Detailed Specification: History: ------------------------------------------------------------------ Number: RU-004 Title: Subset of Fortran Standard which does not include redundant features Submitted By: Russian Federation (GOST R) WG5 Status: Rejected, May 2005 Severity Level: More than 4 References: Basic Functionality: Define subset of Fortran Standard which does not include redundant features. Rationale: Fortran 2003 is a rather complicated language. Subset of Fortran standard should not contain the old, obsolete and redundant features. This would be useful for new Fortran users and for new Fortran applications. The F language plus some new features of Fortran 2003 may be used as a base for a such subset. Estimated Impact: No effect on existing programs. Detailed Specification: History: ------------------------------------------------------------------ Number: RU-005 Title: Extend a set of array intrinsic functions Submitted By: Russian Federation (GOST R) WG5 Status: Accepted as second priority item after modification as per N1637, May 2005 Development Status: Specification, edits complete Severity Level: 4 (or 5) References: HPF Original Proposal: Extend a set of array intrinsic functions, for example add some intrinsic functions of HPF. Rationale: The additional array intrinsic functions of HPF are useful for some applications (especially reduction functions). Modified to read (in N1637): WG5 proposes to add the following intrinsics from the HPF version 2.0 Standard to the Fortran Standard. From HPF version 2.0 paragraph 7.5.4: IALL(ARRAY, DIM, MASK) Bitwise logical AND reduction Optional DIM, MASK IANY(ARRAY, DIM, MASK) Bitwise logical OR reduction Optional DIM, MASK IPARITY(ARRAY, DIM, MASK) Bitwise logical EOR reduction Optional DIM, MASK PARITY(MASK, DIM) Logical EOR reduction Optional DIM From HPF version 2.0 paragraph 7.5.6: ALL_PREFIX(MASK, DIM, SEGMENT, EXCLUSIVE) Optional DIM, SEGMENT, EXCLUSIVE ALL_SUFFIX(MASK, DIM, SEGMENT, EXCLUSIVE) Optional DIM, SEGMENT, EXCLUSIVE ANY_PREFIX(MASK, DIM, SEGMENT, EXCLUSIVE) Optional DIM, SEGMENT, EXCLUSIVE ANY_SUFFIX(MASK, DIM, SEGMENT, EXCLUSIVE) Optional DIM, SEGMENT, EXCLUSIVE IALL_PREFIX(ARRAY, DIM, MASK, SEGMENT, EXCLUSIVE) Optional DIM, MASK, SEGMENT, EXCLUSIVE IALL_SUFFIX(ARRAY, DIM, MASK, SEGMENT, EXCLUSIVE) Optional DIM, MASK, SEGMENT, EXCLUSIVE IANY_PREFIX(ARRAY, DIM, MASK, SEGMENT, EXCLUSIVE) Optional DIM, MASK, SEGMENT, EXCLUSIVE IANY_SUFFIX(ARRAY, DIM, MASK, SEGMENT, EXCLUSIVE) Optional DIM, MASK, SEGMENT, EXCLUSIVE IPARITY_PREFIX(ARRAY, DIM, MASK, SEGMENT, EXCLUSIVE) Optional DIM, MASK, SEGMENT, EXCLUSIVE IPARITY_SUFFIX(ARRAY, DIM, MASK, SEGMENT, EXCLUSIVE) Optional DIM, MASK, SEGMENT, EXCLUSIVE PARITY_PREFIX(MASK, DIM, SEGMENT, EXCLUSIVE) Optional DIM, SEGMENT, EXCLUSIVE PARITY_SUFFIX(MASK, DIM, SEGMENT, EXCLUSIVE) Optional DIM, SEGMENT, EXCLUSIVE PRODUCT_PREFIX(ARRAY, DIM, MASK, SEGMENT, EXCLUSIVE) Optional DIM, MASK, SEGMENT, EXCLUSIVE PRODUCT_SUFFIX(ARRAY, DIM, MASK, SEGMENT, EXCLUSIVE) Optional DIM, MASK, SEGMENT, EXCLUSIVE SUM_PREFIX(ARRAY, DIM, MASK, SEGMENT, EXCLUSIVE) Optional DIM, MASK, SEGMENT, EXCLUSIVE SUM_SUFFIX(ARRAY, DIM, MASK, SEGMENT, EXCLUSIVE) Optional DIM, MASK, SEGMENT, EXCLUSIVE Estimated Impact: Additions to the Section 13. No effect on existing programs. Detailed Specification: History: ------------------------------------------------------------------ Number: RU-006 Title: Give a table with attribute compatibility Submitted By: Russian Federation (GOST R) WG5 Status: Decision deferred, May 2005 SeveritStatus: For Consideration 2 References: Basic Functionality: Give a table with attribute compatibility. Such a table should show which attributes may be used together to specify an entity. Rationale: Describing constraints on mutual using of specifications of attributes in type declaration statements is rather cumbersome (complicated). Such a table should contain all combinations of constraints. Estimated Impact: No effect on existing programs. Addition to the Section 5 (or to the Annex C). Detailed Specification: History: ------------------------------------------------------------------ Number: UK-001 (revision of 25 April 2005) Title: Co-arrays for parallel programming Submitted By: UK WG5 Status: Accepted as first priority item after modification as per J3/05-183r1, May 2005 Development Status: Specification, syntax complete Severity Level: 6 References: ISO/IEC JTC1/SC22/WG5 N1317 Basic Functionality: Co-arrays provide a simple parallel extension of Fortran. The extension assumes the SPMD programming model with the program replicated a fixed number of times. Each copy is called an image. Normal subscripts refer to memory addresses within an image while a second set of subscripts refer to an image. Each image executes asynchronously with explicit synchronization provided by the programmer. For example, the statement REAL, DIMENSION(N)[*] :: X,Y declares that each image has two real arrays of size N. When an image executes the statement X(:) = Y(:)[Q] it makes a copy of the array Y from the memory of image Q into array X in the memory of the image executing the statement. A reference to X or Y without its second set of subscripts is a reference to the local array. Rationale: It is our belief that the wide adoption of this extension, compared with other parallel programming models, would lead to easier program development, faster execution times, and better program maintainability, particularly where the number of processes is large. Fortran 95 included language features needed by HPF in the expectation that HPF would become widely used for parallel programming. Unfortunately, this has not happened because HPF is difficult to implement and its performance in practice is often disappointing. Furthermore, its ability to represent complicated data distributions is limited. Instead MPI has become the de-facto standard for parallel programming. MPI is awkward to program and its performance tends to decay as the number of processes increases. MPI is essentially a library of C procedures, and the overhead from calling these procedures often limits scalability for programs that generate many small messages. In contrast, co-arrays add additional syntax to the language that requires support in the compiler. They allow the programmer to design complicated data distributions and to write customized communication patterns using a Fortran-like syntax. The lack of any external library call, coupled with the fact that the extension has been designed to be easy to implement, gives great scope for communications optimization compared with either HPF or MPI codes. Estimated Impact: Other features would be little affected since execution is normal and normal optimizations are applicable except where there is explicit co-array syntax. Uniprocessors would be required to recognize the syntax but can ignore most of it and, if asked, would indicate that the number of images is one. Detailed Specification: See J3/05-208, a further development of J3/05-183r1 History: Presented by John Reid at the 1998 meeting of WG5 in Trollhattan. --------------------------------------------------------------------- Number: UK-002 Title: Decimal floating point arithmetic Submitted By: UK WG5 Status: Accepted as first priority item, May 2005 Development Status: Specification, edits complete Severity Level: 3 References: 1. A Summary of Densely Packed Decimal encoding http://www2.hursley.ibm.com/decimal/DPDecimal.html 2. Draft changes to the C language for decimal arithmetic WG14-N1016 http://std.dkuug.dk/JTC1/SC22/WG14/www/documents Basic Functionality: To allow for decimal floating point arithmetic Rationale: Languages increasingly support decimal arithmetic in addition to binary or hexadecimal arithmetic, e.g. C#, COBOL, Visual Basic. Now that IBM are about to sell hardware with packed decimal floating point, C and C++ are preparing TRs to extend those languages to provide decimal floating-point facilities, principally for financial applications. In order to retain competitiveness and to maintain interoperability with C, Fortran should adopt comparable facilities. Estimated Impact: no effect on existing programs Detailed Specification: Current hardware developments give a form of packed decimal holding three decimal digits in ten bits. However this proposal for Fortran does not depend on the hardware format and allows for the possibility that within a single program unit some real variables may be held and operated upon in decimal form and some in binary or hexadecimal (or other radix) form, and that the default radix for the processor may be any of these. History: ---------------------------------------------------------------------- Number: UK-003 Title: Conformance to IEEE 754R (IEEE Standard for Floating-Point Arithmetic) Submitted By: UK WG5 Status: Accepted as second priority item, May 2005 Development Status: For Consideration Severity Level: 4 References: 1. IEEE 754R-200x (IEEE Standard for Floating-Point Arithmetic) This is still being developed. The March 2004 document is at http://www.validlab.com/754R/drafts/754r.pdf 2. Draft changes to the C language for decimal arithmetic WG14-N1016 http://std.dkuug.dk/JTC1/SC22/WG14/www/documents Basic Functionality: To allow for decimal floating point arithmetic in conformance with IEEE 754R Rationale: Other languages, notably C and C++, are being extended to accommodate features of IEEE 754R, principally for decimal floating point arithmetic. In order to retain interoperability with C, Fortran should adopt comparable facilities. Estimated Impact: no effect on existing programs Detailed Specification: This proposal is dependent on facilities to specify decimal arithmetic being adopted separately. It is necessarily an outline specification as IEEE 754R is not yet complete. 1. Add reference to IEEE 754R in section 1.9. 2. Add new intrinsic procedures as required by IEEE 754R section 5 (Operations) and Appendix L (Language extensions) to section 14 of the Fortran base language. Depending on details in the final form of IEEE 754R, some procedures may be added to section 13. References to the term "IEEE arithmetic", which occur mainly in section 14 but also in sections 7, 13 and 15, may need to be redefined. History: ---------------------------------------------------------------------- Number: UK-004 Title: KIND environment specification Submitted By: UK WG5 Status: Decision deferred, May 2005 Development Status: For Consideration Severity Level: 3 References: Basic Functionality: Provide prespecified parameter arrays in FORTRAN_ENV that define the number (size of array) and available kind values for each intrinsic type. Rationale: For many programs it would be useful if it were possible to find the number of different kinds available for the intrinsic types and the actual kind values assigned by the processor. Estimated Impact: Little or no effect on existing programs Detailed Specification: I would expect there to be declarations like the following defined in ISO_FORTRAN_ENV INTEGER,PARAMETER:: FP_KINDS(3) = (/4,8,16/), & INT_KINDS(2) = (/4,2/), & CHAR_KINDS(1)= (/1/)... An additional requirement would be that FP_KINDS(1) must be the value for KIND(0.0E0) and FP_KINDS(2) that of KIND(0.0D0). Similarly the first element in each array must contain the kind value for the default intrinsic type. An inquiry as to the SIZE(FP_KINDS) will return the information as to the number of floating point, etc. representation methods available. History: ---------------------------------------------------------------------- Number: UK-005 Title: Long Integers Submitted by: UK WG5 Status: Accepted as first priority item, May 2005 Development Status: Specification, edits complete Severity Level: 4 References: Basic Functionality: Require the support of long integers declared thus: integer, parameter :: long = selected_int_kind(18) integer (long) :: l,m,n Rationale: Long integers are needed increasingly in large programs, but if we make the above declaration in a program we cannot be sure that it will compile. Estimated Impact: No new syntax is involved, so the edits to the standard will be very simple - just a few sentences for the requirement and perhaps a note. Most compilers already support long integers and would need no change. Detailed Specification: Require the support of integers whose kind type parameter value is selected_int_kind(18). History: ---------------------------------------------------------------------- Number: UK-006 Title: Multiple Nonzero-Rank Part References Submitted By: UK WG5 Status: Decision deferred, May 2005 Development Status: For Consideration Severity Level: 4 References: J3/03-253 Basic Functionality: Allow array sections that are 'arrays of arrays', for example, a(:,:)%comp(:,:) while maintaining the rule that no pointer or allocatable component can occur after a part that has nonzero rank. Rationale: These are not allowed because when such an array is passed to a dummy argument dum, a(i,j)%comp(k,l) corresponds to dum(k,l,i,j) and the more array parts there are, the more confusing it is seen to be. However, programmers would soon get used to the rule and it is not hard to state. The constraint means a significant loss of functionality. It disallows the use of all the powerful array syntax and intrinsics for data stored inside derived types. Estimated Impact: The edits needed to implement this are small and localized to Section 6.1.2. References with multiple non-zero part-refs are treated in all respects like data-refs with just a single non-zero rank part-ref, namely, they are array sections. The implementation of this feature does require some nontrivial work. However, the steps involved are very similar to the way current data-refs and array pointers/sections are handled. Detailed Specification: The main edits needed are the following: [105:12]. In C614, delete "There shall not be more then one with nonzero rank.". [105:14]. Change line to "The rank of a is the sum of the ranks of the s with nonzero rank, if any; otherwise, the rank is zero." [105:15+]. Add paragraph: "The shape of a is the rank-1 array obtained by concatenating the shapes of the nonzero rank s in backward order, that is, starting from the final ." History: ---------------------------------------------------------------------- Number: UK-007 Title: Pointer function references as actual arguments Submitted by: UK WG5 Status: Accepted as first priority item, May 2005 Development Status: Specification, edits complete Severity Level: 4 References: N1612 interp (F95) 000074 Basic Functionality: Allow references to functions returning an associated pointer to appear as actual arguments associated with INTENT(OUT) dummies. This is parallel to the way regular pointers are treated. Example: FUNCTION storage(key) RESULT(loc) INTEGER, INTENT(IN) :: key REAL, POINTER :: loc loc=>... END FUNCTION ! Make the following legal CALL RANDOM_NUMBER(storage(10)) Rationale: The proposed change makes the language more symmetrical. It arose from considering interpretation request F95/000074, entitled "TARGET dummy arguments and POINTER expressions", for which it was decided that in Fortran 2003 function results are not definable even when they are pointers associated with a TARGET. However, the functionality of allowing code like the one in the example above is needed in the language. Also there is inconsistency with the way pointer variables are treated. Estimated Impact: As interp 000074 showed, the standard is already a little murky on whether function results are definable, so changes to the standard will be small. The cost for implementations will be small. Detailed Specification: The text which describes argument association has problems in that it often confuses the actual argument with the "thing" that the dummy is associated with. Once that text is clarified the above example should become legal. History: Based on a proposal by Aleksander Donev ---------------------------------------------------------------------- Number: UK-008 Title: Pointer function references as lhs in assignment Submitted by: UK WG5 Status: Accepted as second priority item, May 2005 Development Status: Specification, syntax, edits complete Severity Level: 4 References: N1612 interp (F95/) 000074 Basic Functionality: Allow references to functions returning an associated pointer to appear as the lhs of assignment statement, where the value of the target is changed. This is parallel to the way regular pointers are treated. Example: FUNCTION storage(key) RESULT(loc) INTEGER, INTENT(IN) :: key REAL, POINTER :: loc loc=>... END FUNCTION ! Make the following legal storage(5)=0.5 Rationale: The proposed change makes the language more symmetrical. It arose from considering interpretation request F95/000074, entitled "TARGET dummy arguments and POINTER expressions". The proposed change also brings in a very useful functionality: it allows one to change between different data structures with little to no change in the source code. Consider an example of a dictionary data structure, where the keys are INTEGER and the data values are REAL. A simple implementation might use an array to store the values: TYPE :: Dictionary_t REAL, DIMENSION(:), ALLOCATABLE :: storage ... END TYPE Later however, a more sophisticated data-structure (say a hash-table) that conserves memory may be implemented, substituting the array with a pointer-valued function which returns a pointer to the storage location corresponding to the key: TYPE :: Dictionary_t REAL, DIMENSION(:), ALLOCATABLE :: storage CONTAINS PROCEDURE :: storage ! See previous function END TYPE FUNCTION storage(dictionary, key) RESULT(loc) CLASS(Dictionary_t), INTENT(INOUT) :: dictionary INTEGER, INTENT(IN) :: key REAL, POINTER :: loc loc=>... END FUNCTION The text of the code will need minor changes: TYPE(Dictionary_t) :: dictionary ... dictionary%storage(5)=0.5 Another example in numerical problems includes switching from full to sparse storage for a matrix without having to change all the references. Estimated Impact: The proposed change requires introducing new syntax rules. However it is simple in nature. The cost to implementations will be low. Detailed Specification: Add a second form of in 7.4.1.1 in R734: is = is or where is a and is a pointer History: Based on a proposal by Aleksander Donev ---------------------------------------------------------------------- Number: UK-009 Title: Use procedureness in generic resolution Submitted By: UK WG5 Status: Accepted as second priority item, May 2005 Development Status: Specification, edits complete Severity Level: 3 Reference: Basic Functionality: Allow the procedureness of an argument to be used to disambiguate generic procedure references. Rationale: One can always tell whether a name (or designator) is that of a procedure or of a data object. Users complain that since THEY can tell the difference, why can the compiler not? Estimated Impact: Localized change to 16.2.3. Small effect on implementations. Detailed Specification: Allow whether an argument is a procedure to be used to disambiguate generic procedure references. Deciding which specific procedure to invoke already takes account of this (it requires that the actual arguments be "consistent" with the specific), all we have to do is to allow a generic set to include specifics whose only difference is whether an argument is a procedure. History: ---------------------------------------------------------------------- Number: UK-010 Title: Partial initialization of PARAMETERs Submitted By: UK WG5 Status: Rejected, May 2005 Development Status: For Consideration Severity Level: 3-4 (depending on technical approach). Reference: Basic Functionality: Allow independent subobjects of a PARAMETER to be initialized by separate statements. Rationale: A frequently-heard complaint is the awkwardness of being required to initialize (inevitably huge) PARAMETER arrays in a single statement. Estimated Impact: The edits will mostly be local to clause 5, depending on the approach taken. Detailed Specification: Allow independent subobjects of a PARAMETER to be initialized by separate statements. To keep it simple, no access to the value of a PARAMETER should be allowed until all of it has been initialized. This could be done as simply as allowing PARAMETERs to be initialized in DATA statements, but other approaches might have technical merit. Suggested Syntax: Three possible syntaxes for this feature are described here, with their advantages and disadvantages listed. (1) Allow the DATA statement to be used on PARAMETERs. + Easy to standardize (gives a severity level of 3). + Easy to implement (compilers can already parse DATA statements). + Easy to learn (users already know about DATA). + Identical treatment of variables and parameters. - Cannot use expressions in the initializers. - Some people think DATA is old-fashioned. (2) Extend the syntax of the PARAMETER statement; in particular, allow " = ". + No new keyword needed. + Users recognize that PARAMETER is about parameters. + Can use expressions in the initializers. - Not as easy to standardize/implement/learn (severity 4). - Does not allow expressions to initialize subobjects of variables. - Some people think the PARAMETER statement is old-fashioned. (3) Do it with a new statement, e.g. "FUNKY :: = ". + Could handle variables/parameters consistently. + Syntax less "quirky" than DATA. - Not as easy to standardize/implement/learn (severity 4). - DATA will still be quirky anyway. Note: The only technical disadvantage of the simplest approach (use DATA) is the lack of expression initializers. This could be overcome by extending the syntax of DATA, e.g. to allow DATA(A(1:10) = [(i,i=1,10)]) History: ---------------------------------------------------------------------- Number: UK-011 Title: Elemental procedures that are not pure Submitted by: UK WG5 Status: For Consideration Development Status: Specification, syntax, edits complete Severity Level: 3/4 References: Basic Functionality: Allow elemental procedures that are not pure. Indeterminacy can be avoided by specifying that these operate in array element order. Rationale: The problem lies in the (excessive) number of user procedures that need to be written to provide elemental functionality in the case where the PURE requirements cannot be met. With 1 argument, the number is 8, with 2 it is 22, with 3 it is 50; and these will rise to 16, 46, 106 with the agreed increase of maximum rank to 15. Having so many versions is not merely tiresome but also harder to maintain and understand. Furthermore, not addressing this problem inhibits portability to processors which support higher rank than the standard-mandated minimum. The existing elemental procedure facility conflates two ideas: (1) multi-processor performance: a PURE procedure can be invoked on each processor at the same time (assuming any runtime support routines such as the memory allocator and internal i/o library are re-entrant). (2) to define functions or operations which operate elementwise on conforming arrays/scalars. Only the second is inherent in the concept of "elemental"; the first is little more than a potential performance enhancement. The requirement on ELEMENTAL procedures of purity is disadvantageous in the following situations: (i) Debugging is made more difficult, because of the impossibility of inserting PRINT statements. (ii) An elemental operation cannot update a global "operation count" variable, so a suite of such procedures cannot be instrumented to do that kind of performance analysis. (iii) A suite of elemental operations cannot write a log file documenting the operations performed (this is similar to item ii). (iv) An example of an application which finds it prohibitively difficult to use elemental procedures is reverse-mode automatic differentiation (because of the need to produce an execution graph for the reverse mode derivative evaluation). (v) Error handling is forced into the model of returning the error state as part of the result, complicating use of the such a function (and perhaps losing error indications as a consequence). Alternative models such as executing a STOP statement or updating a global error indicator are prohibited by the PURE requirements. (vi) Although a global variable can be used to communicate information from a non-PURE procedure to an ELEMENTAL operation, it cannot effectively be used to do so from one PURE procedure to another. This is particularly germane to operators which by their nature have no optional arguments which could be used to convey anciliary information (such as the accuracy required). This proposal solves the problem without introducing very much new syntax. Furthermore, many other cases are evaluated in array element order (e.g. MAXLOC, i/o, ...) so this is a familiar concept. An impure elemental should be allowed in WHERE (the serialisation requirement might impact performance, but there is no semantic difficulty), but not allowed in FORALL (it would be inappropriate in FORALL: there, purity is the requirement, rather than elementalisability). Another problematic case that would be solved by this is the problem of specifying final subroutines for a datatype. In the not unlikely situation of the final subroutine being impure, this avoids the non-portable and tediously wordy explosion of subroutines based on rank. (Indeed, the original proposed version of final subroutines contained an attempt to address this - via "pseudo-elemental" procedure - though this version proved too complicated and unsystematic to make it into F2003. We should address the problem systematically now, before we make it worse.) Detailed Specification: Introduce a new keyword, IMPURE, which is the opposite of PURE. (A plausible alternative keyword would be SERIAL, as in SERIAL ELEMENTAL; but IMPURE seems attractive...) An ELEMENTAL procedure remains PURE by default but may be declared IMPURE. Such a procedure must still satisfy the "elemental" requirements but need not satisfy the "pure" requirements. As before, a non-ELEMENTAL procedure is IMPURE by default but may be declared PURE. For consistency, since an ELEMENTAL procedure may redundantly be declared PURE, allow a non-ELEMENTAL procedure to be redundantly declared IMPURE. Edits to J3/04-007: [18:16-17] In the final two lines of the third paragraph of 2.4.5, delete ", and all such element operations may be performed in any order or simultaneously". [129:2] In the line before NOTE 7.13, delete "The processor may perform the element-by-element operations in any order." [129:4] In the sentence after NOTE 7.13, delete ", in any order,". [142:28] In the first sentence of the second paragraph of 7.4.1.5, delete ", in any order,". [280:2+] Add to R1228, after "<> PURE": <> IMPURE [280:5+] Add constraint on R1227: C1241a (R1227) A prefix shall not specify both PURE and IMPURE. [281:1] In the line after NOTE 12.37, after "ELEMENTAL appears" add "and IMPURE does not appear". [281:3-4] Replace the paragraph before NOTE 12.37 by If the ELEMENTAL appears, the subprogram is an elemental subprogram. If the ELEMENTAL appears and IMPURE does not appear, the subprogram is a pure elemental subprogram and shall meet the additional constraints of 12.7.1. [282:26] In the penultimate paragraph of 12.5.2.2, after "ELEMENTAL appears" add "and IMPURE does not appear". [284:19] In the penultimate paragraph of 12.5.2.4, after "ELEMENTAL is specified" add "and IMPURE is not specified". [286:9] In the second paragraph of 12.6, after "ELEMENTAL" add "and does not have the IMPURE". [287:13] In the second paragraph of 12.7.1, replace the second line by "program unless it has the IMPURE. The". [287:14] In the final line of the second paragraph of 12.7.1, before "elemental" add "pure". [287:15] In C1277 change "an elemental" to "a pure elemental". [287:17] In C1278 change "an elemental" to "a pure elemental". [288:2] In C1279 change "an elemental" to "a pure elemental". [288:11] In the line before NOTE 12.48, replace "in any order" by "in array element order" and add the sentence "If the elemental function is pure, the values of the elements, if any, of the result are the same as would have been obtained if the scalar function had been applied separately in any order." [289:8-9] In the last two lines of the first paragraph of 12.7.3, replace "in any order" by "in array element order" and add the sentence "If the elemental subroutine is pure, the values of the elements, if any, of the results are the same as would have been obtained if the subroutine had been applied separately to corresponding elements of each array actual argument in any order." Estimated Impact: On implementations, noticeable but not major. History: --------------------------------------------------------------- Number: UK-012 Title: Recursive I/O Submitted By: UK WG5 Status: For Consideration Development Status: Specification, edits complete Severity Level : 3 References: Basic Functionality: Allow I/O on other units during execution of an I/O statement Rationale: It is useful to be able to call tracing and diagnostic I/O routines in a subprogram used within an I/O statement. This facility is commonly available in other languages and the present prohibition appears to be an anomaly in the standard. Estimated Impact: Minimal on standard and on processors; no impact on existing programs. Discussion: F77 explicitly prohibited recursive I/O (section 12.11). However with the changes to recursion in Fortran from F90 onwards, and with many Fortran processors and most other languages permitting recursive I/O, it is anomalous that the Fortran standard does not. It is proposed to remove the restriction on I/O to or from other units during execution of an I/O statement. Detailed Specification: [219:10] After "an an external unit" insert "that is identified by another input/output statement being executed" so that the entire paragraph reads: A recursive input/output statement shall not identify an external unit that is identified by another input/output statement being executed except that a child data transfer statement may identify its parent data transfer statement external unit. The UK is undecided about whether or not the following note should be added at 219:11+. If is offered for consideration by WG5 NOTE For example, suppose fun is a function that writes a warning on unit 11 if something suspicious happens. In this case, the statement write(12,*) 'This is the value of fun(x)', fun(x) is valid since a different unit is employed. Alternatively, or in addition, add an item to the list of changes in the Introduction (currently p xiii item (5)). History: --------------------------------------------------------------------