From J.Reid@letterbox.rl.ac.uk Fri Oct 27 19:19:48 1995 Received: from letterbox.rl.ac.uk (letterbox.rl.ac.uk [130.246.8.100]) by dkuug.dk (8.6.12/8.6.12) with SMTP id TAA12325 for ; Fri, 27 Oct 1995 19:18:57 +0100 Received: from jkr.cc.rl.ac.uk by letterbox.rl.ac.uk with SMTP (PP) id ; Fri, 27 Oct 1995 18:18:40 +0000 Received: by jkr.cc.rl.ac.uk (4.1/SMI-4.1) id AA05912; Fri, 27 Oct 95 18:19:23 GMT Date: Fri, 27 Oct 95 18:19:23 GMT From: jkr@letterbox.rl.ac.uk (John Reid) Message-Id: <9510271819.AA05912@jkr.cc.rl.ac.uk> To: SC22WG5@dkuug.dk Subject: Draft repository Here is a draft of the new repository. Is this OK? John Reid. ............................................................................... ISO/IEC JTC1/SC22/WG5 - N??? Repository of Requirements Draft of 27 October 1995 (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. The Status: field is one of the following: For Consideration, Accepted for ___ Revision, Accepted for ___ Revision, with changes, Requested for ___ Revision, Being Investigated for ___ Revision, Being Developed for ___ Revision, Rejected (reasons must be given). Status may not change from Accepted to Being Developed until the Specification field is complete. This field contains all relevant material for the chosen development body. If the status is Being Developed, two additional fields are supplied: Target Date for Completion, Progress. Progress may be Satisfactory or Unsatisfactory. If it is Unsatisfactory, corrective action will be required by WG5 as detailed in Standing Document 4 - the WG5 Strategic Plan. When a proposed revision is adopted as a standard, all items implemented in that revision are removed from Standing Document 5. Items are never renumbered. A Rejected item will be retained unless WG5 votes to remove it. ------------------- The draft 1995 standard will be reviewed at the WG5 meeting scheduled for November 6-10, 1995, and plans for Fortran 2000 will be made then. At its 1995 meeting, WG5 adopted the following resolutions: T8. Handling Floating Point Exceptions That WG5 intends to produce a Technical Report in 1996 on handling floating point exceptions in Fortran; Wolfgang Walter is appointed interim Project Editor and is charged to assemble a development body and to identify a Project Editor. The target schedule and initial content of this technical report are described in document WG5-N1117. T9. Interoperability with C That WG5 intends to produce a Technical Report in 1996 on interoperability with C; Jamie Shiers is appointed interim Project Editor and is charged to assemble a development body and to identify a Project Editor. The target schedule and outline content of this technical report are described in document WG5-N1114. T10. Data Type Enhancements That WG5 intends to produce a Technical Report on handling data type enhancements that include allocatable components and parameterized derived types; Lawrie Schonfelder is appointed interim Project Editor and is charged to assemble a development body and to identify a Project Editor. The target schedule and outline content of this technical report are described in document WG5-N1115. T11. Standard Preprocessor for Fortran That WG5 recognizes that preprocessing facilities are an important consideration for many members of the Fortran community. However WG5 does not believe that such facilities should be incorporated into the Fortran Standard (ISO/IEC IS 1539-1). WG5 therefore invites members and member bodies to make proposals for further action, including specification of requirements and nominations for project editor. Note: The following items have been removed, since their disposition has been agreed. They may be viewed by anonymous ftp to jkr.cc.rl.ac.uk (130.246.8.20) in the file pub/wg5/repository.done 1 Change Initial Status of Pointers to Disassociated 1a Allow Pointer Initialization with a Target 1b Allow Initialization of Pointer Status 3a Features to be declared obsolescent in F96 4 Namelist Comments 8 CONSTANT as a synonym for PARAMETER 9 Minimal Field Width Editing 10 Exact Field Width Editing 12 Process time from System Clock 13 FORALL statement 13a FORALL 22 Implicit Initialization of Structure Components 28 Pure User Functions and Subroutines 29 Add DIM parameter to MAXLOC and MINLOC intrinsic functions 30 Remove conflicts with IEC 559 (IEEE 754, IEEE 854) 31 Allow some classes of user-defined functions in declarations 35 User Defined Elemental Functions 36 Nested WHERE 39 Optional generic-spec on END INTERFACE 40 Automatic deallocation of allocatable arrays Change bars show other differences from the 1994 repository (N1060). A new item has a change bar only on its first line. ------------------- Contents of Repository 2 Controlling Pointer Bounds 3 Language Evolution 5 Exception Handling 5a Exception Handling 5b Condition Handling 5c Exception Handling 6 Conditional Compilation 7 Block Comments 11 Aliasing Type Definitions 14 Parameterised Derived Types 14a Kind Parameters for Derived Types 15 Remove name class irregularities 16 Allow ALLOCATABLE derived-type components 16a Allocatable arrays as dummy arguments | 17 Derived Type I/O 18 Object Oriented Programming 19 Standardization of performance directives 19a Directives | 20 Command Line Arguments and Environmental Variables 21 Bit Data Type, String 23 Multi-threaded execution facilities 24 Remove the restriction on the maximum rank of arrays 24a Greater than 7 Array Dimensions | 25 Extend the semantics of the EXIT statement 26 Selecting subarrays of non-rectangular form 27 Parallel sections construct 32 Support IEC 559 conforming or similar hardware 33 Nesting of internal procedures 34 Varying length character with declared maximum 37 Unsigned INTEGER Data Type 38 Improve Interoperability between Fortran and ANSI C 38a Improve Interoperability between Fortran and C | 41 Renaming of in USE | 42 Allow internal procedures as actual arguments | 43 Procedure variables | 43a Pointers to Procedures | 44 Regularize Handling of Pointer Arguments | 44a INTENT for pointers | 45 Minor Technical Enhancements | 46 Packaging Implementer Specific Intrinsics in MODULEs | 47 POSIX Binding to Fortran 90 | 48 Variable Repeat Specifiers in Formats | 49 Specifying Default Precisions | 50 Remove limitation on statement length | 51 Annex of processor dependent items | 52 Asynchronous I/O (proposed HPFF work) | Number: 2 Title: Controlling Pointer Bounds Submitted By: US Status: For Consideration References: N780, Nxxx Basic Functionality: Allow a user to specify the bounds of a pointer that is associated with a target by the pointer assignment statement. Rationale: Currently a pointer that is associated with a target by the pointer assignment statement has the bounds of the target unless the target is an array section or an array expression, in which case the lower bound is one and the upper bound is the extent. The user has no control over setting the bounds. This is inconsistent with the passing of an actual argument array, array section, or array expression to a dummy argument. The lower bound of a dummy argument may be specified in a declaration statement. A user should have a similar amount of control over the bounds of array pointers. Estimated Impact: This affects only the pointer facility. It will not invalidate any existing programs. Detailed Specification: History: Presented to WG5 by Jeanne Martin at the Victoria meeting in July, 1992. Number: 3 Title: Language Evolution Submitted By: Aurelio Pollicini, Germany Status: Requested for 2000 Revision References: N781, N817, N902 Basic Functionality: A management plan for language evolution: move redundant features to the obsolescent list, design strategic functionality, and integrate the whole into a coherent language. Rationale: A language cannot continue to grow forever by the addition of new features. There must be some cleansing, that is, the removal of features no longer needed or features whose functionality is provided by better features. Estimated Impact: While the language would be improved, suppliers of processors would have to provide means to process existing code, such as continuing to support removed features or providing translators. Detailed Specification: (Germany) Germany believes that the 2001 revision of Fortran should be a further major revision of the language. In deciding how the language should evolve for use in the next millennium the major trends in both system design and in language technology should be studied, e.g. OOP. In the first instance this revision should attempt to complete and regularize the functionalities already a part of Fortran of the 90's, therefore redundant features should be declared obsolescent. The obsolescent features of F90 should be moved into the obsolete category, and a new set of obsolescent features should be defined. The revision planned for 2001 should be a more comprehensive updating of the language and as such the requirements specification will need to be completed relatively sooner to allow the implementation body time to elaborate the necessary document changes. Germany believes that the following list of features are essentially redundant and their use in new Fortran code to be generally undesirable. We would wish to signal that should they fall into disuse, as we would hope, then they will be candidates for removal in a future revision of the Fortran language. - Computed GOTO - Statement Function - DATA statement among the executables - EQUIVALENCE statement - All equivalence facilities based on storage association in COMMON blocks should be declared obsolescent History: Presented to WG5 by Aurelio Pollicini at the Victoria meeting in July, 1992. Requested for 1995 Revision via B9/B4.2 Language evolution items accepted for 1995 Revision, Aug 1994, see X3J3/009/007. Number: 5 Title: Exception Handling Submitted By: IFIP WG 2.5 Status: Being developed for 2000 Revision | References: N848, N908 Basic Functionality: A mechanism for reporting arithmetic exceptions. A simple mechanism could be provided by an ENABLE construct and a pair of intrinsics. Rationale: This is necessary for the construction of reliable software. Estimated Impact: Impacts subprogram communication which will have fairly significant impact on existing processors. Would not affect existing programs. Detailed Specification: X3J3/94-258r4 History: Request received by Convenor from IFIP WG 2.5, October 14, 1992 Request for investigation via B9/C5 Development Body established, July 1995, to produce a | Technical Report in 1996 on handling floating | point exceptions. | Number: 5a Title: Exception Handling Submitted By: Germany Status: Being developed for 2000 Revision | References: N902 Basic Functionality: There is a clear need to include facilities in the F96 language to handle exceptions. There should be both a simple standard mechanism for handling exceptions and a set of defined standard exception conditions, e.g. divide by zero but without user-defined conditions, which would complicate things significantly. But the design must be done extremely carefully such that Fortran, which had overcome the GOTOs with a 20-year delay, will not develop into a "COME FROM" language, the other extreme. Additional features in F2001 should provide much needed extensions and regular completion of the exception handling design successfully initiated in F96. We should extend the exception handling by adding comprehensive facilities to this standard to handle errors and exceptions. There should be both an extended set of defined standard exception conditions, which also encompass user-defined conditions, and a standard mechanism for handling these exceptions. Rationale: This facility is necessary for writing portable arithmetic software. Estimated Impact: Detailed Specification: X3J3/94-258r4 History: Request for investigation via B9/C5 Development Body established, July 1995, to produce a | Technical Report in 1996 on handling floating | point exceptions. | Number: 5b Title: Condition Handling Submitted By: US Status: Being developed for 2000 Revision | References: Section F.4 of X3J3/S8.104 (Appendix F) N900 Basic Functionality: Provide a structured way of dealing with relatively rare, synchronous events, such as error in input data or instability of an algorithm near a critical point. Rationale: A structured approach to handling exceptional conditions would improve both the maintainability and robustness of Fortran programs. Much of the error handling code which clutters up the expression of the underlying algorithm in current programs could instead be moved to a separate handler. Such handlers would, in turn, encourage programmers to write, and provide facilities to support, more complete code for dealing with exceptional conditions. A block-structured approach would preserve, for both the programmer and the compiler, a clear connection between the code expressing an algorithm and the associated exception handling code. Estimated Impact: Detailed Specification: The condition handling mechanism must have the following characteristics: 1. Automatic detection and signaling (when enabled) of a standard set of intrinsic conditions, including at least: numeric errors, subscript and substring bounds errors, I/O errors, end of file, and allocation errors. Additional, processor-dependent intrinsic conditions should also be allowed. 2. User-defined conditions, declared with a new specification statement and signaled explicitly by a new executable statement. 3. Dummy condition arguments. 4. Independent enabling and/or disabling of intrinsic conditions, on a granularity finer than that of a scoping unit; that is, it should be possible to enable an intrinsic condition only for a block of statements, possibly even a single statement, in a scoping unit. 5. Minimal impact on code performance within the innermost condition-handling block or scoping unit. In other words, entities in the innermost block or scoping unit should be permitted to become undefined when a condition is signaled when necessary to avoid extra processor overhead. 6. When a condition is signaled, a search should be made up the chain of nested, enabled condition-handling blocks and scoping units for an associated user-written handler, and control should be transferred to the first such handler found. If no handler is found, the result is processor dependent. A handler should be able to resignal the condition that activated it. 7. Default handlers to handle any condition. 8. Appropriate inquiry functions to determine whether a condition has been enabled and whether a handler has been established for it. History: Request for investigation via B9/C5 Development Body established, July 1995, to produce a | Technical Report in 1996 on handling floating | point exceptions. | Number: 5c Title: Exception Handling Submitted by: UK (also requested by Russia) Status: Being developed for 2000 Revision | References: S8.104, section F.4, June 1987. N909, N919 Basic Functionality: Allows specification of action to be taken at an exception. Rationale: There is a clear need to include facilities in the language to handle exceptions. There should be both a standard mechanism for handling exceptions and a set of defined standard exception conditions, e.g. divide by zero. Estimated Impact: No effect on existing standard-conforming programs. Significant effect on processors. Detailed specification: The UK is willing to produce a detailed specification if requested by WG5. It should be a significant simplification of the proposal in X3J3/S8.104, section F.4. History: Submitted by UK Panel, June 1993. Request for investigation via B9/C5 Development Body established, July 1995, to produce a | Technical Report in 1996 on handling floating | point exceptions. | Number: 6 Title: Conditional Compilation Submitted By: US (also requested by Russia) Status: Rejected (see Tokyo resolution T12) | References: N539, N900, N919 Basic Functionality: Permit the conditional inclusion of Fortran statements (declarations, executable constructs, comment lines, procedures, etc.) in programs. The conditions are based on the values of compile-time variables. Rationale: This would permit users to maintain only one version of a source for use on various systems or under various conditions. The C language has such facilities and users have found them invaluable. Estimated Impact: No impact on existing programs. Would add slightly to the burden of implementers. Detailed Specification: History: Brought up in HPF deliberations in December 1992. A letter of request from HPFF is forthcoming; no formal request has been received as yet. This feature was also suggested in the Fortran 90 Implementers Workshop in 1991. April 1995: Toyko resolution T11 favoured action other than | incorporation into ISO/IEC IS 1539-1. | Number: 7 Title: Block Comments Submitted by: Canadian Fortran Working Group Status: For Consideration Reference: N901 Basic Functionality: This would allow the specification of lengthy commentary, without the need to precede every line of such commentary with the comment symbol "!" or "C". It would also facilitate the temporary removal of blocks of code from a program during its development stages. Rationale: The description of basic functionality explains the rationale quite well. Estimated Impact: Very little. There is no syntax construction we can think of using "(!", and none using "!)". Furthermore, it seems that there is no valid statement which could end with "(", with a comment "!" symbol following, and it seems very unlikely that commentary in existing programs would start with ")", so chances of breaking existing programs seems slight. It also does not seem likely that this will present much of a problem for compiler writers; such text is simply eliminated during parsing of the program. Since the first "!)" will terminate the commentary, no bracketing levels have to be monitored. Detailed Specification: Informally, the pair of symbols "(!" would indicate the start of commentary. All text from (and including) "(!" would be commentary until the first occurrence of "!)", which would also be considered commentary. This would include all text following "(!" on the same line, all text preceding "!)" on the final line, and all lines of text between. Since the old source form should (in our opinion) be deprecated, and since we feel there is no sense perpetuating deprecated features, we only propose text to allow this form in free form source. Specifically, we propose that: 1. The first sentence of 3.3.1.1 be modified by adding "or within a block comment" before the ".". 2. Change "If" in the third sentence to "If a line is not part of a block comment, and if". 3. The paragraph be split into two paragraphs at the end of the third line of the paragraph. 4. A new paragraph be added after the first paragraph and before the second paragraph, to read: "The character pair "(!" initiates a block comment, except when it appears in a character context. The block comment extends to (and includes) the first subsequent appearance of the character pair "!)". Lines appearing after the line where the block comment was initiated and before the line where the block comment terminates are comment lines. Characters appearing after the pair "!)" which terminates the comment and on the same line are interpreted as if they appeared on a line with the characters from the beginning of the line to and including the character pair "!)" deleted. History: Number: 11 Title: Aliasing Type Definitions Submitted By: Canadian Fortran Working Group Status: For Consideration References: N901 Basic Functionality: To give the ability for programmers to use one type name as an alias for another. Rationale: One of the arguments favoring Fortran 90 over 77 is that it is much easier to deal with the single/double precision issue using a named kind parameter and the intrinsic Selected_Real_Kind. A second new feature concerns the ability to define operators. Let us now consider a code which has been written in which all real variable declarations are of the form REAL(stnd), where stnd is an appropriate kind value. To obtain results using different underlying hardware precisions on a specific machine, one only has to redefine stnd, e.g. integer, parameter :: stnd = selected_real_kind (14,50) or integer, parameter :: stnd = selected_real_kind ( 7,30) But now suppose that computations are required to much higher precision than that available on that machine. Fortran 90 makes *most* of this very easy. One may first define a new type, say type VERYLONG as some appropriate record structure. Then one can define a module containing procedures to perform the arithmetic operations on objects, A and B say, of this new type. Then one can define operators to invoke these new procedures. One has then to do very little to modify the existing algorithm to make it compute to very high precision. First, put the definition of type VERYLONG in a module, say HIGH, along with the interface definitions and procedures to do the extended arithmetic. Then, in each program unit, add a statement USE HIGH Finally, (***and this is the ringer***) change all declarations such as real(stnd) :: a, b to type (VERYLONG) :: a,b The program will now compute to very high precision, with NO changes being required in the executable statements of the program...i.e. the statement a = a*b does NOT need to be changed to a function call, as was the case with Fortran 77. The one step in this which is awkward, and should somehow be unnecessary, is having to manually change declarations of the form Real(stnd) to a different form, Type(VERYLONG). The main intent of this proposal is to remove the need to change the form of any type declarations. With the proposed new syntax below, one could write Type Float :: ALIAS = real(stnd) or Type Float :: ALIAS = type(VERYLONG) In all programs of the algorithm, actual declarations would then be given, for example, as type(Float) :: a,b To change an existing program to function in very high precision, one would then only have to change the definition of type float. That would only have to be done in a single place. Estimated Impact: The impact on software developers could be significant, as this could represent a notable simplification. The impact on existing programs should be nonexistent, since the syntax and semantics proposed are not currently permitted. It is thought that the impact on compilers will not be large. They will simply have to recognize that one type name is simply a synonym for some other type name. Detailed Specification: Before section 4.5, add a new section (and renumber 4.5 as 4.6): 4.5 Alias types The specification of the name of one type may serve as an alias for the specification of some other type. R430a alias-type-spec is TYPE type-name :: ALIAS = type-spec Constraint: The type-spec appearing on the right hand side of an alias-type-spec must have been previously defined. If an alias type-name is specified in an alias-type-spec, then any subsequent appearance of the alias type-name as a type-spec has exactly the same effect as if objects declared with that alias type-name were in fact declared with the type-spec appearing on the right hand side of the alias-type-spec. History: Both John Reid and Malcolm Cohen are to be thanked for comments on an early draft of this proposal which eliminated some errors and ambiguities. (Any remaining errors are of course our fault.) Number: 14 Title: Parameterised Derived Types Submitted By: Germany Status: Being developed for 2000 Revision | References: N902 Basic Functionality: allow derived types to have both kind and non-kind type parameters. Rationale: All the intrinsic types are parameterised but the derived types are not. This is already greatly restricting the use of derived types in any context where selected kind intrinsic types are used. A common requirement is to have libraries of procedures that are generic over floating-point kinds. This is straightforward in F90 provided all arguments are of intrinsic type; the kind parameterisation supports this well. This is not the case if arguments of a derived type are required because the lack of parameterisation requires separately defined types and separately named types for each relevant kind. Similarly the lack of parameterisation of derived types means that separate modules would need to be written for each character kind, with different type names etc., for a facility like the varying string module. Germany would prefer introducing this extension to deal with both kind and non-kind type parameters with derived types in Fortran 96. Estimated Impact: Detailed Specification: History: Request for investigation via B9/C2 August 1994: decided to delay this addition to 2000. Development Body established, July 1995, to produce a | Technical Report in 1996 on data type enhancements. | Number: 14a Title: Kind Parameters for Derived Types Submitted by: UK Status: Being developed for 2000 Revision | References: N909 Basic Functionality: Allows derived types to have Kind parameters. Rationale: The lack of Parameterised Derived Types is a glaring anomaly in F90. All the intrinsic types are parameterised but the derived types are not. This is already greatly restricting the use of derived types in any context where selected kind intrinsic types are used. A common requirement is for libraries of procedures that are generic over floating-point kinds. This is straightforward in F90 provided all arguments are of intrinsic type; the kind parameterisation enables this well. This is not the case if any argument of a derived type is required because the lack of parameterisation requires separately defined and named types for each relevant kind. Similarly the lack of parameterisation of derived types means that separate modules would need to be written for each character kind, with different type names etc., for a facility like the varying string module. Very nearly complete proposals existed in F8x which were dropped as part of the political processes leading to the finally adopted version of the language. These could be used as an indication of the possibilities for developing an extension to meet this need. Estimated Impact: No effect on existing standard-conforming programs. Medium impact on processors. Detailed Specification: The UK believes that the Fortran 96 development body would wish to define the detailed specification but the UK is willing to provide a detailed specification if requested. The following serves to illustrate the requirement. The basic idea behind the proposals involved in this area for F8x was that a type definition could include a set of essentially dummy parameters of type integer. These could be used in any specification expressions used to declare values such as lengths and bounds for components. When a structure of such a type was declared, actual values would have to be provided again by specification expressions for these parameters; hence determining the relevant values for the components. The complication is on how to deal with KIND type parameters where the values have to be statically determinable. We are suggesting here that a restrictive but practical solution to this problem is to allow only one kind type parameter for any derived type and that this be called KIND. This restricted parameterisation would nevertheless allow all but the most esoteric types to be created and problems to be programmed. We could with this proposal define types TYPE VECTOR3(KIND) REAL(KIND=KIND) :: x(3) ENDTYPE VECTOR3 TYPE VECTOR4(KIND) REAL(KIND=KIND) :: x(4) ENDTYPE VECTOR4 We could then declare variables INTEGER,PARAMETER :: sp=KIND(0.0),dp=KIND(0.0D0) type(VECTOR3(sp)) :: displ,vel,acceln type(VECTOR4(dp)) :: spacetime,mmtmeng where the variables for displacement, velocity and acceleration are declared as single precision three-vectors, and the spacetime and momentum-energy vectors are declared as double precision four-vectors. As in the F8x proposal, each such type declaration implicitly creates a KIND inquiry function with argument of the type. This inquiry function returns the declared value for the KIND parameter of the argument. Because of the special nature of KIND, this is simply an overload of the existing generic function. The overloads will be resolved by the type of the argument. In structure declarations and elsewhere, the KIND parameter value must be determined by a static expression. History: Request for investigation via B9/C2 August 1994: decided to delay this addition to 2000. Development Body established, July 1995, to produce a | Technical Report in 1996 on data type enhancements. | Number: 15 Title: Remove name class irregularities Submitted By: Germany Status: For Consideration References: N902r Basic Functionality: Remove derived-type names and construct names from the class of local entities. Rationale: The classes of names are too restrictive and include too many quite dissimilar entities in the same class of local entities. This situation should be examined and the restrictions possibly removed. Estimated Impact: Detailed Specification: The class membership of derived type names should be revised. The current position is that formally derived-types are defined to be in the same class as variable names. However, other more logical restrictions on the use of derived type names suggest they should form a class of "type names". The derived type name should be a member of a separate class of type-names along with the intrinsic type names, and not part of the local variable name class. Since construct names can never be confused with any other local name, there is no reason for their inclusion in this class. Construct names are always identifiable as such by the syntax and context of their appearance. In fact, a construct name is essentially a creation of the construct it names. There is no logical reason why two non-overlapping constructs in the same program unit should not have the same construct name. The context will always determine which actual construct is involved; the scope of a construct name could be that of the construct named. History: Number: 16 Title: Allow ALLOCATABLE derived-type components Submitted By: Germany, UK Status: Being developed for 2000 Revision | References: N902r, N909, N931 Basic Functionality: Allow ALLOCATABLE derived-type components Rationale: This would allow for very much more efficient implementation of applications using dynamic sized, but otherwise simple, structures instead of the currently required pointer components. For example, if the varying-string module were based on the type TYPE string CHARACTER,ALLOCATABLE :: chars(:) ENDTYPE string it is likely that implementations based on straightforward compilation of the published module would be much more efficient. Estimated Impact: Allows notably more efficient execution of programs. No effect on existing programs. Small effect on compilers. Detailed Specification: History: Requested for 1995 Revision via B9/B3 Development Body established, July 1995, to produce a | Technical Report in 1996 on data type enhancements. | Number: 16a | Title: Allocatable arrays as dummy arguments Submitted By: UK Status: For Consideration for F2000 References: Basic Functionality: Allow allocatable arrays as dummy arguments. Rationale: This would allow for very much more efficient implementation of applications using dynamic sized, but otherwise simple, arrays instead of the currently required pointer arrays. Estimated Impact: Allows notably more efficient execution of programs. No effect on existing programs. Small effect on compilers. Detailed Specification: Allow allocatable arrays as dummy arguments. The interface must be explicit and the corresponding actual argument must be an allocatable array. History: Number: 17 Title: Derived Type I/O Submitted By: Germany, UK Status: Being investigated for 2000 Revision References: N902 Basic Functionality: Extends intrinsic input/output syntax to cover derived types. Rationale: The lack of proper facilities to extend the intrinsic I/O syntax and semantics to cover derived type objects properly is a major constraint on both proper data-abstraction/semantic-extension capabilities and will similarly constrain any attempts to extend these ideas further into "Object Oriented" programming. Estimated Impact: No effect on existing standard-conforming programs. Medium effect on processors. Detailed specification: The UK is willing to produce a detailed specification if requested by WG5. History: Request for investigation via B9/C7 Number: 18 Title: Object Oriented Programming Submitted By: Germany, UK Status: Being investigated for 2000 Revision References: N902, N909 Basic Functionality: Allows the object-oriented model to be realized in Fortran. Rationale: The F2001 language must provide support for and interfacing capability to object oriented programming. Much of the data-abstraction infra-structure included in F90 is already OO but there are other features of the OOP paradigm that need to be considered, if for no other reason that F2001 programs will have to be able to call/invoke facilities from libraries built in other languages to exploit OO techniques. One specific defect which hampers both the semantic extension and object oriented paradigms stems from the inability for the user of a type extension module to declare named constants of a type whose structure is private. This is essential for true OOP. This problem arises because of the classification of expressions and the restrictions placed on what may appear in initialization expressions. The F90 classification of expressions is overly restrictive, complicated and irregular. We have general expressions which are employed in the general execution of the program. These can use any data-object and procedure that is accessible and defined at the point of execution. However we also have constant expressions, initialization expressions, restricted expressions, specification expressions and KIND expressions. These have highly involved overlapping definitions relating to the restrictions that apply and the contexts in which they must be used. These should be extensively revised and restrictions applied only where absolutely necessary. Since we require that the KIND of an object be determined at compilation it is essential that expressions determining KIND values, wherever they might occur, can be evaluated statically. PARAMETER values, except where they are used to determine KIND values, do not strictly need to be known at compile time. They, along with the initial values for variables, need be known only at load time or even as late as the first invocation of the procedure. Specification expressions where array bounds and character lengths are determined do not have to be evaluated, and frequently cannot even now be evaluated, until run time. This analysis leads to a simpler and less restrictive classification of expressions: - KIND or static expressions that involve primaries that are literal constants, symbolic constants whose values are determined by static expressions, possibly involving intrinsic operators, and a restricted set of intrinsic functions; - Initialization expressions that involve primaries that are static expressions, accessible explicit procedures that are proper functions; and - Specification expressions that involve any data-object or proper function that is accessible and defined at the time of invocation of the program or procedure We need to define "proper function". This would need to be a function whose value was uniquely determined by its arguments and which had no side effects. (The HPF concept of the PURE procedure is relevant here). This relaxation has vast benefits in allowing regularisation of treatment of derived type and intrinsic type objects. For instance, it allows the override definition of assignment to be used to initialize structure variables where this is necessary. It would also with the changes above allow the construction of facilities for a user to declare structured symbolic constants when USEing a type with its structure declared PRIVATE. These are necessary steps towards full data-abstraction and OO facilities but require small upward compatible changes to the existing language. There would be other more significant changes and additions to fully support a Fortran flavor of the OO paradigm. Estimated Impact: No effect on existing standard-conforming programs. Medium effect on processors. Detailed specification: The UK panel is willing to provide detailed specifications if requested by WG5. History: Request for investigation via B9/C6 Object initialization accepted for 1995 Revision, Aug 1994, see X3J3/009/006. Subgroup established to investigate whether this should be the direction of the 2000 revision, Aug 1994. Number: 19 Title: Standardization of performance directives Submitted By: Germany Status: For Consideration References: N902r Basic Functionality: Currently, several Fortran processors offer language extensions (directives) for the specification of assertions which enable the processors to create more efficient object code. It would be highly desirable if such language extensions could be standardized to preserve the efficiency of a program if it is migrated to a different Fortran processor. Rationale: These optimization directives may e.g. allow to specify: - for a function that it is free of side effects (i.e. does not change global data, does not perform I/O, etc.), - for a function that its body should preferably be expanded inline at each invocation rather then generating "call"- instructions, - for expressions that the evaluation order of terms may be changed arbitrarily, - for variables that some relations hold with some likelihood at a particular point of the program (it could e.g. be specified at the beginning of a DO loop that the expression defining the number of iterations is probably larger than e.g. 100 - the compiler may then decide to use vector or scalar instructions for the loop depending on this information). Syntactically these language extensions are Fortran comments with a special syntax within the comment text to keep the Fortran program portable (i.e. a standard Fortran processor will consider the optimization hints as normal comments and will ignore them). Estimated Impact: Detailed Specification: History: Number: 19a | Title: Directives Submitted By: US Status: For Consideration References: X3J3 JOR 95-004r1 item 026 Basic Functionality: Provide a suggested DIRECTIVE syntax for Fortran programmers. Rationale: Users of Fortran would benefit from more commonality of directives, and better mechanisms for identifying directives which are not safe to ignore. Estimated Impact: Detailed Specification: History: Aug 95, meeting 134: Unarchived, approved by US TAG for F2000 as medium priority Number: 20 Title: Command Line Arguments and Environmental Variables Submitted By: US - subsequently withdrawn for possible consolidation with other requirements Status: For Consideration References: N900 Basic Functionality: Provide a standard method to retrieve the command line arguments. This capability is analogous to the ARGC/ARGV convention of ANSI-C. Although not a fundamental requirement, also provide a standard method to retrieve environmental variables. Rationale: Getting command line arguments is obviously desirable since it has been implemented in a vendor-specific manner on a wide variety of machines and a wide variety of compilers. The basic functionality appears to be common among implementations. However, there appears to be no de facto standard means to specify it. Some systems also offer environmental variables, symbols, or logical device names. Some of this functionality could be incorporated by an intrinsic which when passed a character variable returns a processor-defined result. When this character variable is omitted, the command line is returned. Note that not all environments have a command line to return. However, an implementation should return a status field and one status can be that there is no processor-defined command line to return. By analogy, the DATE_AND_TIME intrinsic is provided even though some systems do not have real-time clocks. Estimated Impact: This should not have an effect on existing code unless the intrinsic(s) clash with existing procedure names. A summary of some vendor-specific implementations: 1. Microsoft Fortran: NARGS() is a function which returns the number of arguments. GETARG(THSARG,ARGMNT,STATUS) is a subroutine where THSARG specifies which command line argument is desired (0=program name), ARGMNT is the actual command line argument, and STATUS is a status: if < 0, an error occurred. If > 0, it is the length of the command line argument returned 2. Lahey Fortran: subroutine GETCL returns a string containing the command tail -- everything after the command and the blank separator. 3. HP has a function IARGC() which returns the number of arguments and a subroutine GETARG(THSARG,ARG) which returns the THSARG- th argument from the built-in ARG array. 4. VAX-VMS Fortran requires that the program be invoked as a "foreign command." Subroutine LIB$GET_FOREIGN (COMMAND_LINE, PROMPT, COMMAND_LEN, FLAGS) is called where COMMAND_LINE returns the command line tail, PROMPT displays a prompt for the user to supply a command line tail interactively, COMMAND_LEN optionally returns the length of the command line tail, and FLAGS is an argument for a "utility command collector" not needed for this application. 5. IBM AIX/6000: GETARG(I, C) is a subroutine where I specifies which command line argument to return (0=program name), C is an argument of type character and will contain, upon return from GETARG, the command line argument. Subroutine GETENV('ENVNAM',RESULT) stores in character variable RESULT the value of the environmental variable ENVNAM in the profile file of the current directory. Detailed Specification: A proposed format for this intrinsic or group of intrinsics has not been provided since other existing implementations should be considered. However, some of the facilities in the POSIX binding to Fortran 77 already provide this functionality and should be seriously considered. Desirable features are: 1. Parallel syntax or optional arguments to specify either environmental variables or the command line. 2. Ability to treat the command line as either a string or as a series of arguments. This is similar to the DATE/TIME vs. VALUES option in the DATE_AND_TIME routine. 3. Ability to provide an error status including the fact that no command line can be provided or the specified environmental variable did not exist. 4. Automatic parsing of the command line based on blank delimiters since many users want this feature without the bother of using the string intrinsics. 5. Allowing for systems which can only return the command line tail vs. systems which can return the full command line. Open issues may include: 1. How to specify the length of the character variables for the command line arguments. 2. How to specify the dimension of the array returning the command line arguments. History: Number: 21 Title: Bit Data Type, String Submitted By: US (also requested by Russia - could be provided as a standard module) Status: For Consideration References: Section F.1.1 of S8.104 (Appendix F) N900, N919 Basic Functionality: Add BIT data type using the syntax and semantics of CHARACTER type, i.e., declaration syntax would be identical to CHARACTER except for the word BIT. BIT initialization, substring operation, concatenation, and input/output would also parallel CHARACTER. Rationale: Artificial life, genetic algorithms, and cellular automata are exciting, new (the programming community is becoming aware of them) developments. Programming in these fields would be facilitated by the BIT data type. DOD utilizes (requires?) BIT data type. Users have been requesting BIT for years. There are implementations that should be standardized and Fortran 90 features that could be deprecated. Most compilers could generate more efficient code if BIT were an intrinsic type. Estimated Impact: Detailed Specification: Add the attribute UNSIGNED. The attribute's interpretation is discussed further below. Operators: Concatenation (//), the INTEGER arithmetic operators (+, -, *, /, **, .NE., .LT., ...) and the LOGICAL operators (.NOT., .AND., .OR., .EQV., and .NEQV.) which are Boolean when they are used with BIT operands. LOGICAL and BIT operands may not be mixed, i.e., a BIT datum is not .TRUE. or .FALSE.. In addition, consider extending the LOGICAL operators to include all 16 binary operators. It is not necessary for WG5/X3J3 to anticipate how BIT data type will be used, rather, the above requirements would extend all "reasonable" combinations of possibilities to BIT data and operations. The UNSIGNED attribute determines how BIT operands are aligned when the appear as an operand. Signed BIT (the default) is sign extended and truncated similarly, e.g., b(5:7) = B'1111101' has the value 101 stored into the three bits -- user beware. For UNSIGNED, zeros filled on the left. The shift functions from the Mil Standard are also available. The possibility of another attribute LEFT JUSTIFY (the default is RIGHT JUSTIFY) needs to be examined. In an array of BIT strings, the bits of consecutive array elements are contiguous. That is, for BIT*11 A(27) the first bit of A(2) immediately follows the last bit of A(1). BIT variables cannot be EQUIVALENCEd with variables of other types, the same as CHARACTER. But the committee should consider BIT and CHARACTER EQUIVALENCE. BIT variables can be placed in SEQUENCE derived types. This feature has to be examined carefully. Some examples: BIT, UNSIGNED :: bu_1*1, bu_2*2, ... BIT :: b_1*1, b_2*2, ... ... b_2 = b_2(2:) + bu_1 b_4 = b_1 // b_2 // B'1' IF ( 2 * bu_1 + 1 > ... bu_2 = 2*( b_1 .AND. bu_1 ) But not: IF ( bu_1 ) GO TO 10 Since the variables are Boolean, not LOGICAL. Review Appendix F from earlier drafts of the Fortran Standard. History: Number: 23 Title: Multi-threaded execution facilities Submitted by: UK Status: For consideration for 2000/2001 Revision References: N909 Basic Functionality: Allows program execution to proceed using multiple execution threads. Rationale: This facility is needed to make better use of current and likely future architectures. This should be implicit rather than explicit in much the same way as "parallel" execution of array operations is possible without being mandated. The language should provide facilities for whole blocks of code that can be executed out of sequence or in any sequence. Estimated Impact: No effect on existing standard-conforming programs. Medium effect on processors. Detailed specification: The HPF proposals should be studied and used as a guide in production of a detailed specification. History: Number: 24 Title: Remove the restriction on the maximum rank of arrays Submitted By: Russian Fortran Working Group Status: For Consideration References: N713, i.7; N919 Basic Functionality: The rank of arrays may be arbitrary, but it must not be less than seven for the sake of portability. Rationale: This is needed for some application programs. This is useful for the regularization of Fortran features. Estimated Impact: It will not invalidate any existing programs. Detailed Specification: History: Presented to WG5 by the Soviet Fortran Working Group in Feb. 1991. Number: 24a | Title: Greater than 7 Array Dimensions Submitted By: US Status: For Consideration References: X3J3 JOR 95-004r1 item 067 Basic Functionality: The next Fortran standard should have a maximum limit on the number of array dimensions of greater than 7. Processors should be able to support more than that maximum as an extension. Rationale: The original limit of seven dimensions in Fortran was established when Fortran was first published in 1957 and has never been changed since. The number of heavy duty applications which require more than seven dimensions is growing and becoming a significant proportion of high performance applications. Since Fortran does not now support more than seven dimensions, programmers of an application which requires more than seven dimensions usually write their application in another language. They do this even though in most cases they are more familiar with Fortran and would prefer to use Fortran. Estimated Impact: Detailed Specification: History: Aug 95, meeting 134: Change max 255 to >7, approved by US TAG for F2000 as medium priority Number: 25 Title: Extend the semantics of the EXIT statement Submitted By: Russian Fortran Working Group Status: For Consideration References: N713, i.9; 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 reglarization of Fortran features. Estimated Impact: It will not invalidate any existing programs. It will require very little change in existing processors. Detailed Specification: History: Presented to WG5 by Soviet Fortran Working Group in Feb. 1991. Number: 26 Title: Selecting subarrays of non-rectangular form Submitted By: Russian Fortran Working Group Status: For Consideration References: N567, i.11; N713, i.8; N919 Basic Functionality: Allow the use of implied-do control on the right side in the pointer assignment statement. For example: REAL, POINTER :: p_diag(:) REAL, TARGET :: a(10, 10) p_diag => (a(i, i), i = 1:10) Rationale: This extension is useful for some applications. Estimated Impact: It will not invalidate any existing programs. It requires little change in existing processors. Detailed Specification: History: The IDENTIFY statement in earlier drafts of Fortran 90. Requests from users. The version using the pointer facility was presented to WG5 by A. M. Gorelik at the Rotterdam WG5 meeting in 1990 Number: 27 Title: Parallel sections construct Submitted By: Russian Fortran Working Group Status: For Consideration References: PCF Fortran, N919 Basic Functionality: Include the parallel sections construct (parallel blocks), for example as in PCF Fortran. Rationale: This is necessary for parallel processing, but these features are absent in the HPF language specification. Estimated Impact: It will not invalidate any existing programs. Detailed Specification: History: PCF Fortran Number: 32 Title: Binding to IEEE 754 Submitted By: US Status: Being Investigated for 2000 Revision References: X3J3/004/028 Basic Functionality: Bind Fortran to the IEEE standard for Binary Floating Point Arithmetic, ANSI/IEEE 754-1985. Rationale: Sophisticated users are not satisfied with assertions that X+Y is "mathematically" defined somehow. A very large fraction of commercially available computers are IEEE 754 compliant (for some meaning of the word compliant) but using IEEE 754 features from Fortran currently results in non-portable programs. Improving portability of programs is historically an important motivation for Fortran standards efforts. Estimated Impact: For most programs there will be no impact. For programs that were written to some specific platform's IEEE 754 binding there may be modest impact (depending on how the committee chooses to define the standard binding). For non-IEEE-754-based systems there will be no impact. Detailed Specification: To be precise three things are intended: 1) Where Fortran conflicts with IEEE 754, modify Fortran (e.g., alter Fortran to permit -0.0) 2) Where Fortran is vague on how arithmetic works, employ the IEEE 754 definitions (e.g., formal definitions of +, -, *, sqrt, /). 3) Where IEEE 754 provides facilities not currently available in Fortran, provide them (e.g., ability to detect and set NaN, +Inf, -Inf, etc.) History: Jul 93, WG5 meeting: Removal of conflicts recommended by WG5 for 1995 revision (resolution B9, item B2); investigation of full support in 1995 requested (resolution B9, item C4) Number: 33 Title: Nesting of internal procedures Submitted By: US Status: For Consideration References: Section F.3.1 of S8.104 (Appendix F) Nxxx Basic Functionality: An internal procedure may host other internal procedures. Rationale: Internal procedures have a broad spectrum of uses. At one end, as generalizations of statement functions, simple internal procedures are good candidates for in-lining by an aggressive compiler; at the other, because of their limited scope, they provide a convenient way to divide the internals of a large, complex library routine into manageable pieces. Unfortunately, because of the restriction against nesting an internal procedure in the latter category cannot itself take advantage of one in the former. Now that a number of implementers have experience with Fortran 90, the restriction against nesting internal procedures should be reviewed and, if possible, relaxed. Estimated Impact: This will not directly affect existing code. Detailed Specification: History: Number: 34 Title: Varying length character with declared maximum Submitted By: US Status: For Consideration References: N846 Basic Functionality: Fortran has a reputation for allowing users to code algorithms that are readily optimizable. A varying length character type should be added to the language that is consistent with this emphasis on runtime performance. This new character type should provide the flexibility of having varying length (e.g., the user does not have to code the explicit deletion of trailing blanks when referencing a variable of the new character type) and yet it should be possible to code algorithms with this new type that are readily optimizable. Thus the underlying implementation should not require extensive use of dynamic storage. To achieve this, each definition of a variable of this new character type could be required to specify a maximum length. No further intrinsic routines would be needed. Existing syntax for concatenation and substring could be used, with some changes in the semantics. Rationale: A varying length character type allows the manipulation of text of varying lengths without the algorithms having to track where the text of interest ends and the trailing blanks begin. While ISO/N846 provides a varying length character type, a simpler definition would meet the needs of most users without sacrificing runtime performance. Those users that require the robustness of ISO/N846 could use that definition. Estimated Impact: No impact on existing code. [The US proposes this feature for the 2000 revision.] Detailed Specification: Allow a varying length, but require a maximum length also be specified. The maximum length would be a specification expression thus allowing constant and non-constant values. CHARACTER, VARYING :: CHARVAR*10 ! varying length with a maximum ! size of 10 CHARVAR = 'A' ! No padding with trailing blanks CHARVAR = CHARVAR // 'BC' ! Use of existing operator History: Number: 37 Title: Unsigned INTEGER Data Type Submitted By: US Status: For Consideration References: X3J3/004/044 Basic Functionality: The next Fortran standard should require processors to offer full support for unsigned integers as well as signed integers. This support should be required for all types of integers, i.e. for every signed type of integer, there should be an unsigned type. Rationale: Many systems libraries (e.g. Microsoft Windows) are written in other languages and require the use of unsigned integers as arguments to certain functions and subroutines. The availability of unsigned integers will make the interface to these functions and subroutines much more straightforward than it is now. Also, for some types of variables, there is no need for negative values. This feature could also make Fortran more attractive as a development language for systems programmers. Specification of intrinsic data types is a feature that is inherently part of the definition of a programming language. Since there is no standard, there could be different and incompatible implementations from different vendors. Estimated Impact: This requirement has no impact on existing Fortran code. The implementation costs should be quite low, especially since this feature is part of most other programming languages. Detailed Specification: This could be implemented either by having an UNSIGNED keyword immediately prior to the keyword INTEGER in the data type declaration or by using KIND numbers. Possibly all that is needed is a change in the wording of 4.3.1.1 to require representation of both signed and unsigned integers. History: Number: 38 Title: Improve Interoperability between Fortran and ANSI C Submitted By: US Status: Being developed for 2000 Revision | References: X3J3/004/048 Basic Functionality: It should be easy for procedures written in Fortran to call routines written in ANSI C. The Fortran standard should provide methods for specifying the names, data types, argument passing mechanisms, and returned results needed to communicate with ANSI C code. Rationale: Many popular standards and libraries are specified with interfaces written in ANSI C. Because of differences between Fortran and ANSI C concerning, for example, routine calling methods, compatible data and argument passing mechanisms, Fortran users either can not easily use such interfaces or have to use bindings to such interfaces which are awkward, slow, or incomplete. Direct access to such interfaces from Fortran would make these interface more readily available. Estimated Impact: Detailed Specification: History: Subgroup established to investigate the most pressing needs, Aug 1994. Development Body established, July 1995, to produce a | Technical Report in 1996 on Interoperability with C. | Number: 38a | Title: Improve Interoperability between Fortran and C Submitted By: UK Status: For Consideration References: WG5-N1060 item 38 WG5-N1116 ISO/IEC 11404:1995 Language independent datatypes DIS 13886 (1994) Language independent procedure calling. Basic Functionality: It should be easy for procedures written in Fortran and procedures written in C (ISO/IEC 9899:1990) to call each other. WG5 should provide a standard means for specifying procedure interfaces and variables to achieve this. This should be done so far as possible in a way which is extensible to other languages, including future versions of C. Rationale: Fortran has always supported the concept of multi-language programs. Increasingly environments and libraries are designed to interface to C programs. It is very important that these facilities are available equally to Fortran programs in a seamless manner. Estimated Impact: Considerable edits to the standard would be needed if all changes were located in their logical position; minimal edits if changes were collected together in a single section or annex or in a separate document. Detailed Specification: . It is recommended that the development body examine the work of SC22/WG11 (documents 11404 & 13886) where many of the relevant problems have already been discussed and solved. History: Subgroup established to investigate the most pressing needs, Aug 94. Proposal for a Technical Report on this subject approved by WG5, Apr 95. Approved as formal SC22 Work Item, Sep 95. Number: 41 | Title: Renaming of in USE Submitted By: DIN AK Fortran Status: For Consideration References: Draft 1539-1:1996 (x3j3/95-007r1, WG5/N1122), Section 11.3.2 (The USE statement and use association) Basic Functionality: The rules for USE (R1107-R1109) allow the renaming of s of entities in the USEd module, but do not allow the renaming of a in the USEd module. Extend section 11.3.2 to allow for renaming of a , too. Rationale: F90 allows the renaming of s to avoid name clashes if entities defined in different modules have the same name and are to be accessed simultaneously by use association. The same problem can appear for a (R331), because these consist of a sequence of s enclosed in dots (R704, R724). It is therefore necessary to allow USE statements of the form USE geometry, OPERATOR(.max_norm.) => OPERATOR(.dist.) to rename s, or even renaming the of user extensions to the intrinsic operators within a module like USE some_module, OPERATOR(.times.) => OPERATOR(*) which makes all specific procs supplied to an OPERATOR(*) interface in some_module available under the generic operator "name" .times. . The latter may be one step too far, though, since the intrinsic operators are global entities whereas are local entities (14.4). Estimated Impact: This requirement affects only the form of the USE statement. The implementation should be equivalent to the one of renaming a , e.g. checks of uniqueness of the visible specific procedures are identical to those for generic names, and the establishment of a should be identical to the establishment of a . These are only compile-time effects that have no impact on program execution and neglectable impact on compilation speed. Detailed Specification: The following edits to N1122 implement the (minimal) proposal of renaming s only. More general renaming facilities (including renaming between OPERATORs, names, and possibly ASSIGNMENT) may also be considered. In R1108, insert a line 185:23a: <> OPERATOR() => OPERATOR() In R1109, insert a line 185:25a: <> OPERATOR() => OPERATOR() Add a line 185:27a: Constraint: Each shall be a public entity in the module. In 14.1.2.3, at 273:9, change "operator" to "local operator". History: Number: 42 | Title: Allow internal procedures as actual arguments Submitted By: UK Status: For Consideration for F2000 References: Basic Functionality: Allow internal procedures as actual arguments. Rationale: The data for a numerical problem is often expressed in the form of a procedure as well as a set of numbers. Examples are to integrate a function over an interval, to optimize a function over a region, and to solve an equation. Procedure dummy arguments are intended to provide this functionality, but are restricted in Fortran 90, in that the corresponding actual argument is not permitted to be an internal procedure. This prohibits a very convenient mechanism to allow calls of the dummy procedure to access other local data. Here is an example CALL SOLVE (F, A, B, X) ! Solve F(X)=0 in the interval (A,B) ............ CONTAINS FUNCTION F(X) ! By host association, F has access to REAL F, X ! any data that it needs from the environment ! at the point of call of SOLVE. The lack of this facility has meant that library codes often use "reverse communication", where a return is made in place of each call of the dummy procedure. The above example becomes CONTROL = 1 ! Integer variable that controls the calls DO ! Solve F(X)=0 in the interval (A,B) : ! Code to calculate F(X) CALL SOLVE (CONTROL, A, B, X, F) IF (CONTROL==0) EXIT ! The solution has been found END DO This is unnatural at the point of call and leads to poorly structured code in the library procedure. It also means that the library code has either to use the SAVE attribute for its local data (which inhibits parallelism), to make copies of this data on each return, or rely on arrays provided by the user (which may be accidentally corrupted by the user). Estimated Impact: The reason for this restriction is that the host might be a recursive procedure, in which case an indicator of the instance would need to be passed from the dummy procedure argument to the actual argument. However, ... (Malcolm: please add words to explain why this is not a problem). The additions needed to the standard will not be great since all that is needed is to remove a restriction. Note that the interface has to be explicit anyway. Detailed Specification: Allow internal procedures as actual arguments. History: Number: 43 | Title: Procedure variables Submitted By: UK Status: For Consideration for F2000 References: N779 Basic Functionality: Allow variables other than dummy arguments to refer to procedures. Rationale: Procedure variables are useful for providing: Named procedure variables: - callback (event-oriented programming, e.g. X windows) - user program control error handling in libraries (the user can supply an error handler for use by library routines without needing to add lots of code around every library reference). Arrays of procedure variables: - encapsulating command dispatch without requiring a huge centralised SELECT statement (readability and maintainability the issues here) - event handling (e.g. user program event handling from realtime or graphics libraries) Procedure components of derived types - problem encapsulation (e.g. a partial differential equation might be described by several functions for the coefficients, together with data for the initial and boundary conditions). - object encapsulation Estimated Impact: The run-time overheads of invoking a procedure variable that is not a dummy argument should be no different from that for a dummy procedure. The additions needed to the standard will not be great since it builds on the existing rules for agreement between dummy and actual arguments. Detailed Specification: As with dummy arguments, both implicit and explicit interfaces should be allowed for procedure variables. The standard should spell out that it is legal to assign to a procedure variable with an implicit interface any procedure which might legally be called with such an interface (e.g. at one time it might be called with one argument, at another with two). It must be possible to specify an implicit interface subroutine variable in a specification statement, i.e. without the Fortran processor needing to see a CALL statement. It must be possible to (i) reference the procedure referred to by the variable (ii) pass this procedure as an actual argument (iii) assign it to another procedure variable It should also be possible to (iv) include it in a generic specification The syntax for referencing procedure variables should be extended to allow reference the procedure name in a CALL statement or function reference to be any which evaluates to a single procedure. Sample syntax for facility: The starting point for this syntax is to borrow our existing keyword "PROCEDURE" for this purpose; since the existing keyword can currently only appear in a very limited context (as "MODULE PROCEDURE") this avoids introducing a new keyword without confusing the reader by a complicated overload of terminology. Sample syntax for procedure variables: (1) Named variable, implicit interface, function: REAL, PROCEDURE :: F1, F2 PROCEDURE, REAL :: F3 Function reference: X = F1(...) Actual argument: F1 (2) Named variable, implicit interface, subroutine: PROCEDURE :: S1, S2 Subroutine reference: CALL S1(...) Actual argument: S1 Note that this example follows the existing rules for implicit interface typing in a module: that either it is a function with the datatype specified explicitly or it is a subroutine with the datatype not specified at all. Other schemes are possible. (3) Array of subroutines, implicit interface: PROCEDURE, DIMENSION(10) :: P1, P2, P3(2,2) Subroutine reference: CALL P1(1) ! No arguments CALL P3(I,J)(K,L) ! 2 arguments Actual argument: P1(I) P3(1,2) (4) Derived type function component, implicit interface: TYPE metric_space INTEGER :: dimensionality REAL, PROCEDURE :: metric LOGICAL :: continuous END TYPE TYPE(metric_space) :: space1 Function reference: X = space1%metric(...) Actual argument: space1%metric (5) Derived type subroutine component, implicit interface: TYPE user_command CHARACTER*10 :: keyword PROCEDURE :: action LOGICAL :: need_extra_arguments END TYPE TYPE(user_command) :: commands(100) Subroutine reference: CALL commands(I)%action Actual argument: commands(I)%action Of course the more robust situation arises with explicit interfaces: (6) Named function variable, explicit interface: PROCEDURE :: funvar INTERFACE COMPLEX FUNCTION funvar(a,b) DOUBLE PRECISION :: a(:) LOGICAL, OPTIONAL :: b END FUNCTION END INTERFACE (7) Derived type containing some functions: TYPE problem PROCEDURE :: a,b INTERFACE FUNCTION a(x,y) REAL a,x,y END FUNCTION a FUNCTION b(x,y) REAL b,x,y END FUNCTION b END INTERFACE END TYPE problem Note that in this example the "PROCEDURE :: a,b" is not necessary; it is included to keep the syntax completely regular between the ordinary variable case and the component case. A constructor could be used to associate the components with procedures: type(problem) p : p = problem(mya,myb) : call solve(p,... or an assignment statement could be used for individual components: p%a = mya (8) As part of a generic interface (named variables only) PROCEDURE :: specfunvar INTERFACE generic REAL FUNCTION specfunvar(i) INTEGER :: i END FUNCTION END INTERFACE Since we already allow dummy procedures (which might be OPTIONAL) in generic specifications, there seems to be no reason not to allow named procedure variables. Alternative example syntax: PROCEDURE FUNCTION F ! Implicit interface function, implicitly typed PROCEDURE REAL FUNCTION F ! Implicit interface function, explicitly typed PROCEDURE SUBROUTINE F ! Implicit interface subroutine PROCEDURE INTERFACE F ! Explicit interface function/subroutine SUBROUTINE F END SUBROUTINE END PROCEDURE INTERFACE History: Number: 43a | Title: Pointers to Procedures Submitted By: US Status: For Consideration References: X3J3 JOR 95-004r1 item 059 Basic Functionality: Provide pointers which are associated with procedures rather than variables. Rationale: Such pointers would be a more convenient alternative to dummy procedures in many situations because they could be set once rather than having to be respecified in the argument list of each operation. Estimated Impact: Because of the similarity to dummy procedures, most of the text changes would be straightforward. Code changes in conforming processors would likely be similarly straightforward. Detailed Specification: A suggestion: Procedure pointers would be declared with a POINTER declaration plus an interface block (or EXTERNAL statement?). The procedures which could be associated with such a pointer are exactly those that could be associated with a dummy procedure having the same interface. Procedure pointers would be allowed in derived types. There would be no ALLOCATE for procedure pointers. Pointers to procedures associated with an instance of a scoping unit would be valid only for the lifetime of that instance. History: Aug 95, meeting 134: Approved by US TAG for F2000 as medium priority Number: 44 | Title: Regularize Handling of Pointer Arguments Submitted By: US Status: For Consideration References: X3J3 JOR 95-004r1 item 058 Basic Functionality: Treat pointer dummy arguments more like other dummy arguments. Rationale: Reduce surprise. Make operations involving pointers easier to express. Estimated Impact: Most of the textual impact should be in the area describing allowed argument associations. Impact on conforming processors should be similarly contained. Detailed Specification: A suggestion: Allow INTENT specifications on pointer arguments, with the INTENT restrictions applying to the association of the pointer, not the value of the object with which the pointer is associated. Allow "pointer expressions" to be associated with dummy pointers subject to the same restrictions that apply to ordinary expression and dummy variables: the association denoted by the expression is evaluated once and then does not change even if the entities comprising it are modified, and the association of the dummy pointer may not be redefined. Treat a pointer-valued function reference as a "pointer expression" when it is being associated with a dummy pointer. Treat a parenthesized pointer reference as a "pointer expression" when it is being associated with a dummy pointer. Treat a variable with the target attribute as a "pointer expression" (a "pointer constant", if you will) when it is being associated with a dummy pointer. History: Aug 95, meeting 134: Approved by US TAG for F2000 as medium priority Number: 44a | Title: INTENT for pointers Submitted By: UK Status: For Consideration for F2000 References: N779 Basic Functionality: Allow pointers to have the INTENT attribute, which refers to the pointer association status. Rationale: There is a need to allow the first argument of a subroutine that defines an assignment to be a pointer, so that it can allocate the target. X3J3 decided not to allow pointers to have the INTENT attribute because of the ambiguity as to whether it should refer to the association status or the target value. It would be possible to extend the language to permit two intents for pointers. However, there is little point in specifying the intent for the target unless the intent for the association status is IN and this case is covered by not declaring the dummy argument as a pointer. Allowing intent for pointers is a regularization of the language. Estimated Impact: The additions needed to the standard will not be great since all that is needed is to remove the restriction on specifying intent for pointers and specifying that it refers to the pointer association status. Detailed Specification: Pointer dummy arguments are permitted to have the INTENT attribute and this refers to the pointer association status. History: Number: 45 | Title: Minor Technical Enhancements Submitted By: US Status: For Consideration References: X3J3 JOR 95-004r1 item 000 Basic Functionality: This requirement is a placeholder to allow the development body to add small features and enhancements to the Fortran standard as it deems appropriate within the charter and schedule of the current draft effort. Rationale: This allows the development group to get informal agreement on adding small features to the standard without the delay of going through the formal requirements approval process. Estimated Impact: Detailed Specification: History: Aug 95, meeting 134: Submitted, approved by US TAG for F2000 as high priority Number: 46 | Title: Packaging Implementer Specific Intrinsics in MODULEs Submitted By: US Status: For Consideration References: X3J3 JOR 95-004r1 item 027 Basic Functionality: Provide a mechanism to package non-standard intrinsic packages in a portable way. Various other standard activities are specifying new intrinsics as extensions to Fortran, and significantly polluting the name space. Using modules to hide these intrinsics will help reduce name space pollution. Rationale: Facilitates extensions to Fortran environments by other standard bodies (e.g. HPFF, X3H5, POSIX). Estimated Impact: Detailed Specification: See the following references: X3J3/93-170 High Performance Fortran X3H5 document Fortran 90 Defect Item 122 History: Aug 95, meeting 134: Approved by US TAG for F2000 as medium priority Number: 47 | Title: POSIX Binding to Fortran 90 Submitted By: US Status: For Consideration References: X3J3 JOR 95-004r1 item 032 Basic Functionality: Provide, in a separate, collateral standard, a binding for POSIX that makes use of the new features of Fortran 90. Rationale: The existing POSIX binding to Fortran 77 is awkward and inefficient to use due to the limitations of Fortran 77. New features of Fortran 90, particularly modules and derived types, should make a much more natural binding possible. Without such a binding, Fortran (both 77 and 90) will remain a second class language on POSIX-compliant systems. Estimated Impact: Detailed Specification: History: Aug 95, meeting 134: Approved by US TAG for F2000 as medium priority Number: 48 | Title: Variable Repeat Specifiers in Formats Submitted By: US Status: For Consideration References: X3J3 JOR 95-004r1 item 034 Basic Functionality: The language should be capable of repeatable Format specifier [sic; presumably proposer means variable repeat specifiers -- ed.]. For example: 100 FORMAT(1X,N(F6.2,1X),2X,N2X) 110 FORMAT(10X,M(2X,'NO',2X)) where N and M are values defined somewhere in the program by calculation, read, etc. Rationale: This capability would enable tables to be defined by read statements, etc., and make the programs more flexible and easier to write. Estimated Impact: Detailed Specification: History: Aug 95, meeting 134: Approved by US TAG for F2000 as medium priority Number: 49 | Title: Specifying Default Precisions Submitted By: US Status: For Consideration References: X3J3 JOR 95-004r1 item 035 Basic Functionality: Allow a user to specify the precision used for the 'default real' and 'double precision real' types. Rationale: Under the current standard, each floating-point constant must include a suffix specifying the "KIND" or precision, else the interpretation defaults to the 'default real' type with processor-dependent precision. By allowing the programmer to specify the interpretation of 'default real' and/or 'double precision real' in one location per program unit (rather than with each of the individual occurrences of each literal constant) the reliability, portability, and readability of codes could be significantly improved. Many compilers allow such a specification by compiler option. This request is to make such functionality available in the language itself in order to enforce the availability and interpretation of the feature. (An alternative, of course, is to lobby vendors to provide such a feature more uniformly). Estimated Impact: This would not invalidate any existing programs, however, some significant difficulties with storage equivalence might occur if 'default real' and 'double precision real' were set to the same "KIND". Storage equivalence between those types might have to be disallowed in each program unit using this feature. This is already the case with non-default "KIND"s so it should not be an insurmountable difficulty. Detailed Specification: For illustration purposes only: IMPLICIT (REAL,KIND=SELECTED_REAL_KIND(10,30)) (DEFAULT) The above would declare the 'default real' kind to be processor-dependent type which allows 10 decimal digits and an exponent range of at least 30. This would result in the selection of a 64-bit floating-point representation on almost all computers in current production, and is a verbose and indirect way of specifying 'default real' to be what most practitioners would prefer to refer to as "REAL*8". History: Aug 95, meeting 134: Approved by US TAG for F2000 as medium priority Number: 50 | Title: Remove limitation on statement length Submitted By: US Status: For Consideration References: X3J3 JOR 95-004r1 item 075 Basic Functionality: Allow a user to specify large parameter arrays in a simple way: allow more characters in the statement. Rationale: Fortran-90 introduced the useful capability of defining parameter arrays in a single statement. E.g. real, parameter :: a(4) = (/ 1.0, 2.0, 3.0, 4.0 /) According to the f90 language specification, a statement should be less than 132 character on each line, and contain less than 40 continuation lines. This puts severe restrictions on the size of a parameter array. E.g. if the array x(n_dim) is declared as double precision each element may occupy e.g. 16 ascii characters, which means that you may type 8 elements (132/16=8.5) on each line and a total number of 40*8 = 320 elements in the entire statement. This means that n_dim MUST be less than 320. Sometimes it's useful to define larger parameter arrays. E.g. for multi- dimensional arrays containing gauss quadrature or chebyshev coefficients. Estimated Impact: Detailed Specification: A suggestion: This problem may be eliminated in case of the following modification of section 3.3.1.4 in ISO/IEC 1539:1991(E) : Remove the sentence: "A free form statement must not have more than 39 continuation lines." History: Aug 95, meeting 134: Approved by US TAG for F2000 as medium priority Number: 51 | Title: Annex of processor dependent items Submitted By: US Status: For Consideration References: X3J3 JOR 95-004r1 item 077 Basic Functionality: Include in the standard an annex that lists all the language features that have processor dependent aspects. Specifically all the language features where the standard indicates the results/values are processor dependent. This annex is not intended to include language features where there is an implied processor dependent nature (such as the result of arithmetic operations). Rationale: The list of language features where the standard indicates that there are processor dependent aspects appears to be growing with each new release of the standard. It would be helpful for implementers and users if a list in an annex detailed all the language features where some aspect of the semantics needs to be specified by the processor. The benefit for implementers is they get a check list against which to verify that their documentation includes definitions of processor dependent aspects. The benefit for users is they are alerted some areas of the language where they may encounter differences between processors. Once the annex is established further ideas for making use of the information might include (note these are not part of this requirement just ideas): - adding examples to the annex to show ways to write "portable" code with respect to the various items - require a processor to list in their documentation specifics for processor dependent behaviour for the items in the annex. Estimated Impact: Detailed Specification: History: Aug 95, meeting 134: Submitted, approved by US TAG for F2000 as high priority Number: 52 | Title: Asynchronous I/O (proposed HPFF work) Submitted By: US Status: For Consideration References: X3J3 JOR 95-004r1 item 080 Basic Functionality: Permit application control of overlapping computation and I/O. Formatted and unformatted I/O are required. The direction taken by HPF (which has been considering this facility) is similar to the old IBM VS FORTRAN implementation. If practical, this facility should be harmonized with HPF work in this area. It is envisioned that READ and WRITE statements will be augmented to allow control of asynch I/O (if it should occur, and a variable to contain the status of that particular I/O command). In addition a WAIT statement to allow the program to wait for the transaction to complete. It may be necessary or useful to augment the OPEN statement to limit asynch I/O to files that have been opened with for asynch I/O. It should be possible to test if an I/O transaction is completed without waiting. Ideally such a facility would handle multiple outstanding (pending) I/O transactions. Rationale: Advances in CPU performance continue to outstrip advances in input/output device performance. This is further aggravated by the increasing volume of multiprocessor computer systems. Many systems of the late sixties had such facilities (notably the IBM extensions and the CDC BUFFERIN/OUT) supercomputer users have found such facilities invaluable, and it is viewed as important enough in that community to have spawned an HPF subgroup dedicated to defining such a facility. Estimated Impact: It would be necessary to be careful in defining how this interacts with ENABLE. It might be helpful to have loop-local PRIVATE variables. There are probably a number of other interactions not obvious at this time. Detailed Specification: A suggestion: As a first approximation, we should include the HPF text from their last meeting. Note that they are continuing to evolve their proposal. FWIW from memory: OPEN(...,synch='synch|asynch') READ(unit=,fmt=,astat=ivar,...) WRITE(unit=...,astat=ivar,...) WAIT (ivar) ! wait until done STATUS(ivar,iostat=) ! test if done, no wait History: Aug 95, meeting 134: Submitted, approved by US TAG for F2000 as high priority