ISO/IEC/JTC1/SC22/WG5-N1679 Repository of Requirements Version of 26 July 2007 (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 intended for use at the August 2007 WG5 meeting. It represents the status of requirements as decided by WG5 at the conclusion of the previous (February 2006) WG5 meeting. It does not contain a full list of references to J3 papers; this information is in J3 standing document 010. Some, now largely redundant, information from the previous version has not been reproduced here. For this reason N1679 does not totally supersede N1649 and its annexe N1656. The Severity Level is defined in N1594. WG5 summary status is shown in the following table by: A - first priority, B - second priority, D - rejected; items for which a status was decided at the May 2005 meeting and changed at the February 2006 WG5 meeting are denoted by an asterisk. ------------------- Contents of Repository (Reference number, severity level, WG5 summary status, title) J3-001 3 A Enhanced STOP J3-002 3 A GET_IO_UNIT J3-003 4 A EXECUTE_COMMAND_LINE J3-004 3 B STORAGE_SIZE J3-005 3 B C_SIZEOF J3-006 3 D Find all available logical and character kinds J3-007 3/4 D Construct Name Local to Construct J3-008 3 A* Rewrite attribute requirements J3-009 4 D* IO_UNIT standard derived type J3-010 3 A Allow empty CONTAINS part J3-011 5 D Coroutines J3-012 4 B Use ALLOCATABLE and POINTER attributes in generic resolution J3-013 4 A Internal subprograms as actual arguments and procedure pointer targets J3-014 6 B Intelligent macros (supersedes parameterized modules) J3-015 4 B Updating complex parts J3-016 4 B Disassociated or deallocated actual argument associated with nonpointer nonallocatable optional dummy argument is considered not to be present J3-017 4 D Default initial values for absent optional dummy arguments J3-018 4 B Non-null initial targets for pointers J3-019 4 A More mathematical functions J3-020 3 A Allow TYPE ( ) J3-021 4 D Resolve generic without invoking a procedure or evaluating arguments J3-022 4 B Allow a polymorphic allocatable variable in intrinsic assignment J3-023 3 B Named rank-one array constant's extent from its . J3-024 3 B EXIT from any labeled construct J3-025 3 B Allow SUBROUTINE or FUNCTION to be optional on END statements for module and internal subprograms J3-026 3 B ATAN with two arguments works like ATAN2 J3-027 3 A ASCII arguments for LGE etc J3-028 3 B Allow forward type for allocatable components J3-029 3 D More information about GET_COMMAND[_ARGUMENT] failure J3-030 3 B Simplified means to select the most commonly desired real and integer kinds J3-031 4 D ANDTHEN and ORELSE pseudo-functions J3-032 3 B Findloc J3-033 3 B Compiler Version J3-034 3 B Mold on Allocate J3-035 3 B Proposed f2k+ MTE on semicolons J3-036 4 D Use, Except J3-037 4 D Pointers and Targets J3-038 4 B Libm: Bessel, erf, gamma, hypot J3-039 4 A Rank > 7 J3-040 4 D Compute if actual arg is present J3-041 4 B Interoperability of pointers, allocatables, and assumed-shape arrays J3-042 4 B Interoperability of optional arguments J3-043 5 A Pointers to contiguous mem J3-044 4 D* New Intents J3-045 5 D Same Assumed Shape declaration J3-046 5 A DO CONCURRENT construct J3-047 7 B BITS (formerly TYPELESS objects) J3-048 4 B Writing Comma Separated Value CSV files J3-049 4 D Select between expressions RU-001 3 A Remove restriction on the maximum rank of arrays RU-002 3 B Extend the semantics of the EXIT statement RU-003a 4 D* Delete statement functions (originally Extend the obsolescent features list) RU-003b 4 A Obsolesce ENTRY statement RU-004 >4 D Subset of Fortran Standard which does not include redundant features RU-005 4/5 B Extend a set of array intrinsic functions RU-006 2 D Give a table with attribute compatibility UK-001 6 A Co-array Fortran for parallel programming UK-002 3 A Decimal floating point arithmetic UK-003 4 D* Conformance to IEEE 754R UK-004 3 D KIND environment specification UK-005 4 A Long Integers UK-006 4 D Multiple Nonzero-Rank Part References UK-007 4 A Pointer function references as actual arguments UK-008 4 B Pointer function references as lhs in assignment UK-009 3 B Use procedureness in generic resolution UK-010 3/4 D Partial initialization of PARAMETERs UK-011 3/4 B Elemental procedures that are not pure UK-012 3 B Recursive I/O ------------------- Changes from N1649/N1656 to N1679: The table above has been updated to represent the status at the end of the February 2006 meeting; no items have been removed or added except that RU-003 has been split into two for clarity. The titles for J3-014 and J3-047 have been changed. Items J3-041 and J3-042 were, subsequent to the February 2006 meeting, reassigned to be developed as a TR rather than be incorporated as status 'B' items. The WG5 Status for each item below records the history of WG5 decisions about it. The development status, references, history, estimated impact and detailed specifications sections have been removed, as have any detailed edits. The descriptions of J3-014 and J3-047 have been replaced and have not been pruned to the same extent. ------------------- Number: J3-001 Title: Enhanced STOP Submitted By: J3 WG5 Status: Accepted as first priority item, May 2005 Severity Level : 3 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. 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. ------------------------------------------------------------------ Number: J3-002 Title: GET_IO_UNIT Submitted By: J3 WG5 Status: Accepted as first priority item, February 2006 Severity Level : 3 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. ---------------------------------------------------------------- Number: J3-003 Title: EXECUTE_COMMAND_LINE Submitted By: J3 WG5 Status: Accepted as first priority item, May 2005 Severity Level : 4 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. ----------------------------------------------------------------- Number: J3-004 Title: STORAGE_SIZE Submitted By: J3 WG5 Status: Accepted as second priority item, February 2006 Severity Level : 3 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. ------------------------------------------------------------------ Number: J3-005 Title: C_SIZEOF Submitted By: J3 WG5 Status: Accepted as second priority item, February 2006 Severity Level : 3 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. ------------------------------------------------------------------ Number: J3-006 Title: Find all available logical and character kinds Submitted By: J3 WG5 Status: Merged with UK-004 and rejected, February 2006 Severity Level : 3 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. ------------------------------------------------------------------ Number: J3-007 Title: Construct Name Local to Construct Submitted By: J3 WG5 Status: Rejected, May 2005 Severity Level : 3/4 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. ------------------------------------------------------------------ Number: J3-008 Title: Rewrite attribute requirements Submitted by: Malcolm Cohen WG5 Status: Accepted as second priority item, May 2005, Upgraded to first priority item, February 2006 Covers some of RU-006 Severity Level : 3 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. ------------------------------------------------------------------ Number: J3-009 Title: IO_UNIT standard derived type Submitted By: J3 WG5 Status: Accepted as second priority item, May 2005 Rejected, February 2006 Severity Level : 4 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. ------------------------------------------------------------------ Number: J3-010 Title: Allow empty CONTAINS part Submitted By: J3 WG5 Status: Accepted as first priority item, May 2005 Severity Level : 3 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. ------------------------------------------------------------------ Number: J3-011 Title: Coroutines Submitted By: J3 WG5 Status: Rejected, May 2005 Severity Level : 5 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. ------------------------------------------------------------------ Number: J3-012 Title: Use ALLOCATABLE and POINTER attributes in generic resolution Submitted By: J3 WG5 Status: Accepted as second priority item, May 2005 Severity Level : 4 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. ------------------------------------------------------------------ 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 Severity Level : 4 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. ------------------------------------------------------------------ Number: J3-014 Title: Intelligent Macros (supersedes Parameterized module facility) Submitted By: J3 WG5 Status: Original, modified as per J3/05-181r1, accepted as second priority item, May 2005. Intelligent macro form described in J3/05-280 accepted in February 2006. Severity Level : 6 Basic Functionality: Provide a facility whereby a module or subprogram can be developed in a generic form, and then applied to any appropriate type. Provide a Fortran-aware macro facility, integrated with modules, and scoped as normal Fortran entities to avoid name clashes. A macro should be able to be used to create a module (except for the initial MODULE and final END MODULE statements); furthermore a macro should be able to create type definitions, subprograms, and inline sections of code (like an inlined procedure call). It is essential to be able to generate and use local (construct scoped) names, by embedding specification statements in the executable part. Desirable characteristics include the ability within the macro to count, loop, test, generate names (concatenation). Also, macro invocation should be able to use keyword arguments, and optional macro arguments should be possible. Rationale: Many algorithms can be applied to more than one type or kind. It is tedious, expensive, and error prone to develop and maintain program segments that are identical except for type declarations to operate on different types or kinds. A facility is needed to package these in a parameterised manner so that when instantiated they are consistent. Detailed Specification: Macro names to be normal Class 1 names, accessible via use and host association. A macro expands into a set of statements. A macro may contain entire scoping units, but shall not otherwise begin or end a scoping unit. Macro arguments are token sequences limited only by not having unbalanced parentheses or bare commas; names are only interpreted as keywords after expansion (if at all). Tokens can be joined together with a "concatenation operator". Macros should be able to generate statements one piece at a time, via a "continuation operator". Loops should be provided by a MACRO DO (block form only). Testing should be provided by a MACRO IF (block form only). ------------------------------------------------------------------ Number: J3-015 Title: Updating complex parts Submitted By: J3 WG5 Status: Accepted as second priority item, May 2005 Severity Level : 4 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. ------------------------------------------------------------------ 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: Accepted as second priority item, February 2006 Severity Level : 4 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. ------------------------------------------------------------------ Number: J3-017 Title: Default initial values for absent optional dummy arguments Submitted By: J3 WG5 Status: Rejected, May 2005 Severity Level : 4 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. ----------------------------------------------------------------- Number: J3-018 Title: Non-null initial targets for pointers Submitted By: J3 WG5 Status: Accepted as second priority item, May 2005 Severity Level : 4 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. ----------------------------------------------------------------- Number: J3-019 Title: More mathematical functions Submitted By: J3 WG5 Status: Accepted as first priority item, May 2005 Severity Level : 4 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. ------------------------------------------------------------------ Number: J3-020 Title: Allow TYPE ( ) Submitted By: J3 WG5 Status: Accepted as first priority item, May 2005 Severity Level : 3 Basic Functionality: Allow TYPE ( ). Rationale: For regularity and symmetry, allow TYPE ( ). ----------------------------------------------------------------- Number: J3-021 Title: Resolve generic without invoking a procedure or evaluating arguments Submitted By: J3 WG5 Status: Rejected, May 2005 Severity Level : 4 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. ------------------------------------------------------------------ Number: J3-022 Title: Allow a polymorphic allocatable variable in intrinsic assignment Submitted By: J3 WG5 Status: Accepted as second priority item, May 2005 Severity Level : 4 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? ----------------------------------------------------------------- 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 Severity Level : 3 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 . ------------------------------------------------------------------ Number: J3-024 Title: EXIT from any labeled construct Submitted By: J3 WG5 Status: Accepted as second priority item, May 2005, merged with RU-002, February 2006 Severity Level : 3 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 ------------------------------------------------------------------ Number: J3-025 Title: Allow SUBROUTINE or FUNCTION to be optional on END statements for module and internal subprograms Submitted By: J3 WG5 Status: Accepted as second priority item, February 2006 Severity Level : 3 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. ------------------------------------------------------------------ Number: J3-026 Title: ATAN with two arguments works like ATAN2 Submitted By: J3 WG5 Status: Accepted as second priority item, February 2006 Severity Level : 3 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. ------------------------------------------------------------------ Number: J3-027 Title: ASCII arguments for LGE etc Submitted By: J3 WG5 Status: Accepted as first priority item, May 2005 Severity Level : 3 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. ------------------------------------------------------------------ Number: J3-028 Title: Allow forward type for allocatable components Submitted By: J3 WG5 Status: Accepted as second priority item, February 2006 Severity Level : 3 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. ------------------------------------------------------------------ Number: J3-029 Title: More information about GET_COMMAND[_ARGUMENT] failure Submitted By: J3 WG5 Status: Rejected, February 2006 Severity Level : 3 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. ------------------------------------------------------------------ Number: J3-030 Title: Simplified means to select the most commonly desired real and integer kinds Submitted By: J3 WG5 Status: Accepted as second priority item, February 2006 Severity Level : 3 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. ------------------------------------------------------------------ Number: J3-031 Title: ANDTHEN and ORELSE pseudo-functions Submitted By: J3 WG5 Status: Rejected, May 2005 Severity Level : 4 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. ------------------------------------------------------------------ Number: J3-032 Title: FINDLOC Submitted By: J3 WG5 Status: Accepted as second priority item, February 2006 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. ------------------------------------------------------------------ Number: J3-033 Title: Document Processor Version Submitted By: J3 WG5 Status: Accepted as second priority item, February 2006 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. ------------------------------------------------------------------ Number: J3-034 Title: Add MOLD to ALLOCATE Submitted by: J3 WG5 Status: Accepted as second priority item, February 2006 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. ------------------------------------------------------------------ Number: J3-035 Title: Beginning a source line with a semicolon Submitted By: J3 WG5 Status: Accepted as second priority item, February 2006 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. ------------------------------------------------------------------ Number: J3-036 Title: USE, EXCEPT: Submitted By: J3 WG5 Status: Rejected, May 2005 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. ------------------------------------------------------------------ Number: J3-037 Title: Pointers and Targets Submitted By: J3 WG5 Status: Rejected, May 2005 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. ----------------------------------------------------------------- Number: J3-038 Title: C libm functions as Fortran intrinsics Submitted By: J3 WG5 Status: Accepted as second priority item, May 2005 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. ------------------------------------------------------------------ Number: J3-039 Title: Rank > 7 Submitted By: J3 WG5 Status: Accepted as first priority item, May 2005, merged with RU-001, February 2006 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). ------------------------------------------------------------------ Number: J3-040 Title: Compute if actual argument is present Submitted By: J3 WG5 Status: Rejected, May 2005 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). ------------------------------------------------------------------ Number: J3-041 Title: Interoperability of pointers, allocatables, and assumed-shape arrays Submitted By: J3 WG5 Status: Accepted as second priority item, May 2005, merged with J3-042, February 2006; requested by J3 that item be processed as a TR, May 2006, accepted by WG5 by default ballot, July 2006 Basic Functionality: Extensions to C Interop that allow arguments that are pointers, allocatables, and assumed-shape arrays to be interoperable. ------------------------------------------------------------------ Number: J3-042 Title: Interoperability of optional arguments Submitted By: J3 WG5 Status: Accepted as second priority item, May 2005, merged with J3-041, February 2006; requested by J3 that item be processed as a TR, May 2006, accepted by WG5 by default ballot, July 2006 Basic Functionality: Extension to C Interop that allows optional arguments to be interoperable. ------------------------------------------------------------------ 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 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. ------------------------------------------------------------------ Number: J3-044 Title: New Intents Submitted By: J3 WG5 Status: Accepted as first priority item, May 2005, Rejected, February 2006 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. ------------------------------------------------------------------ Number: J3-045 Title: Same shape arrays Submitted By: J3 WG5 Status: Rejected, May 2005 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. ------------------------------------------------------------------ Number: J3-046 Title: DO CONCURRENT Construct Submitted By: J3 WG5 Status: Accepted as first priority item, May 2005 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. ------------------------------------------------------------------ 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 Basic Functionality: A new intrinsic type, BITS, is added. A value of type bits is an ordered sequence of bits. The number of bits in the sequence is specified by the kind type parameter. The default kind value is the size expressed in bits of a numeric storage unit. Binary, octal, and hex constants are of type bits and can, optionally, have a kind parameter specified. Operations include concatenation, relational comparisons, and basic bitwise operations (and, or, xor, not). Rules are specified for handling operands of differing kinds. The relational operators are defined such that they can be mapped to widely available hardware instructions, enabling high performance. Intrinsic procedures are provided for type conversion between bits and integer, logical, real, or complex type. Conversions amount to a replication of the data object's bit pattern, with rules for padding or truncation if the bit sizes of the argument and result differ. Intrinsic assignment involving a bits variable or expression is defined in terms of these conversion intrinsics. Intrinsic procedures are supplied or extended for access to bit manipulations such as shifts, bit merges, and population and leading zero counts. Most of these operations are already available as vendor extensions or as part of the HPF specification, and correspond to single or simple sequences of hardware instructions to enable high performance coding. The HPF functions that were part of the modified RU-005 proposal are also included as part of this feature. Generic resolution based on the kind type parameter of bits actual and corresponding dummy arguments supports writing generic high performance bit manipulation libraries. Bit dummy arguments are allowed to correspond to actual arguments of type bits, integer, logical, real, and complex, which simplifies writing library routines that move blocks of data, and also simplifies interfaces to similar C libraries. Bits type interoperates with both signed and unsigned integer C types. Formatted I/O of bits objects using the I format allows for input and output of these unsigned integer values. List-directed I/O of bits objects uses Z format which permits simple display of the internal representation of data objects. Rationale: Fortran 2003 lacks support for variables that represent a sequence of bits independent of the interpretations imposed by the existing intrinsic data types. Various features have been added to Fortran in the past to facilitate handling sequences of bits by overloading the integer data type, and through vendor extensions, especially in the areas of intrinsic procedures and intrinsic assignment semantics. This has lead to code that is not portable, limiting the usefulness of these features. The BITS data type provides a framework to standardize several of these common Fortran language extensions, and provides a rational method for dealing with BOZ constants. The bits type simplifies and enhances the portable use of Fortran for important classes of non-numeric problems in high performance computing, such as pattern matching, searching and sorting, and low level bit manipulation. Added History: The base specifications and syntax paper for the BITS feature, J3/05-188, was updated to change the way the type parameter is determined for a literal constant, resulting in J3/05-274r3. The base edits paper is J3/06-175r2. Several minor changes were made subsequently during integration and editing to clarify wording and to reduce the scope of the feature. ----------------------------------------------------------------- Number: J3-048 Title: Write CSV files Using LDIO Submitted By: J3 WG5 Status: Accepted as second priority item, May 2005 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. ------------------------------------------------------------------ Number: J3-049 Title: Embed a decision within an expression Submitted By: J3 WG5 Status: Rejected, May 2005 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. ------------------------------------------------------------------ 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 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. ------------------------------------------------------------------ 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 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. ------------------------------------------------------------------ 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, Further modified (wrt statement functions) February 2006 Severity Level: 4 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): a. Move statement functions from the obsolescent feature list to the deleted feature list. b. Make ENTRY statements obsolescent. ------------------------------------------------------------------ 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 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. ------------------------------------------------------------------ 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; merged with J3-047, February 2006 Severity Level: 4 (or 5) 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: [20 prefix and suffix functions] Further modified by WG5 vote (February 2006, v. N1656) to delete all prefix and suffix functions and to merge with J3-047. ------------------------------------------------------------------ Number: RU-006 Title: Give a table with attribute compatibility Submitted By: Russian Federation (GOST R) WG5 Status: Rejected, February 2006, but see J3-008 Severity Level: 2 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. ------------------------------------------------------------------ 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 Severity Level: 6 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. --------------------------------------------------------------------- Number: UK-002 Title: Decimal floating point arithmetic Submitted By: UK WG5 Status: Accepted as first priority item, May 2005 Severity Level: 3 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. ---------------------------------------------------------------------- Number: UK-003 Title: Conformance to IEEE 754R (IEEE Standard for Floating-Point Arithmetic) Submitted By: UK WG5 Status: Rejected, February 2006 Severity Level: 4 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. ---------------------------------------------------------------------- Number: UK-004 Title: KIND environment specification Submitted By: UK WG5 Status: Merged with J3-006 and rejected, February 2006 Severity Level: 3 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. ---------------------------------------------------------------------- Number: UK-005 Title: Long Integers Submitted by: UK WG5 Status: Accepted as first priority item, May 2005 Severity Level: 4 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. ---------------------------------------------------------------------- Number: UK-006 Title: Multiple Nonzero-Rank Part References Submitted By: UK WG5 Status: Rejected, February 2006 Severity Level: 4 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. ---------------------------------------------------------------------- Number: UK-007 Title: Pointer function references as actual arguments Submitted by: UK WG5 Status: Accepted as first priority item, May 2005 Severity Level: 4 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. ---------------------------------------------------------------------- Number: UK-008 Title: Pointer function references as lhs in assignment Submitted by: UK WG5 Status: Accepted as second priority item, May 2005 Severity Level: 4 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. ---------------------------------------------------------------------- Number: UK-009 Title: Use procedureness in generic resolution Submitted By: UK WG5 Status: Accepted as second priority item, May 2005 Severity Level: 3 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? ---------------------------------------------------------------------- Number: UK-010 Title: Partial initialization of PARAMETERs Submitted By: UK WG5 Status: Rejected, May 2005 Severity Level: 3-4 (depending on technical approach). 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. ---------------------------------------------------------------------- Number: UK-011 Title: Elemental procedures that are not pure Submitted by: UK WG5 Status: Accepted as second priority item, February 2006 Severity Level: 3/4 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.) --------------------------------------------------------------- Number: UK-012 Title: Recursive I/O Submitted By: UK WG5 Status: Accepted as second priority item, February 2006 Severity Level : 3 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. 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. -------------------------------------------------------------------