From J.Reid@letterbox.rl.ac.uk Fri Sep 16 10:06:09 1994 Received: from ib.rl.ac.uk by dkuug.dk with SMTP id AA09162 (5.65c8/IDA-1.4.4j for ); Fri, 16 Sep 1994 10:06:09 +0200 Received: from letterbox.rl.ac.uk by ib.rl.ac.uk (IBM VM SMTP V2R1) with TCP; Fri, 16 Sep 94 09:05:35 BST Received: from jkr.cc.rl.ac.uk by letterbox.rl.ac.uk with SMTP (PP) id ; Fri, 16 Sep 1994 09:00:44 +0100 Received: by jkr.cc.rl.ac.uk (4.1/SMI-4.1) id AA12361; Fri, 16 Sep 94 09:03:07 BST Date: Fri, 16 Sep 94 09:03:07 BST From: jkr@letterbox.rl.ac.uk (John Reid) Message-Id: <9409160803.AA12361@jkr.cc.rl.ac.uk> To: SC22WG5@dkuug.dk Subject: Repository X-Charset: ASCII X-Char-Esc: 29 I have made a draft revision of the Repository and append a merge of the old and new versions, so that you can see what I have done. The old version is those lines that start with two spaces or with # and the new version is those lines that start with two spaces or with |. I would be most grateful for your comments. Unfortunately, Jeanne has not had a chance to check it yet because she is at the SC22 meeting and on vacation. Best wishes, John. ............................................................................. | ISO/IEC JTC1/SC22/WG5 - N1060 # ISO/IEC JTC1/SC22/WG5 - N970 Repository of Requirements | Draft of 15 September 1994 # Draft of 21 February 1994 (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, # Requested for ___ Revision, ! New status field # Being Investigated for ___ Revision, ! New status field 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 target date for complete integration in the draft 1995 standard of all items accepted for that revision is March 1, 1995. The draft will be reviewed at the WG5 meeting scheduled for April 17-21, 1995. The development body, X3J3, maintains two relevant standing documents: X3J3/007 is the working draft developed from the previous standard and all approved edits created during the maintenance of that standard plus other editorial improvements; X3J3/009 is a document containing the separate raw proposals approved for incorporation into the draft for the 1995 revision. By March 1, 1995, 009 should be folded into 007 in an editorially consistent manner. | At its 1994 meeting, WG5 adopted a resolution (E14) listing the following | features as required for the 1995 revision: # At its 1993 meeting, WG5 adopted a resolution (B9) listing features accepted # for the 1995 revision (Category A), desired for the 1995 revision (Category B), # and to be investigated for the 1995 revision (Category C). The following # section summarizes those features and indicates the related repository items. # Note that some B9 features had no corresponding repository items at the time # B9 was adopted, and although the items have now been entered in the repository, # they are incomplete. Also some items with the status "Being Developed for # 1995 Revision" have incomplete "Detailed Specification" fields at this time. | 1. Add DIM parameter to MAXLOC and MINLOC intrinsic functions | References: HPF Language Specification, Version 1.0, May 1993 | Repository Item: 29 (from B9 only - incomplete) | X3J3/009/001 | | 2. Comments in namelist input | References: Repository Item: 4 | X3J3/009/002 | | 3. Minimal field width editing | References: Repository Items: 9, 10 | X3J3/009/003 | | 4. FORALL | References: Section F.2.3 of S8.104 (Appendix F) | HPF Language Specification, Version 1.0, May 1993 | Repository Items: 13, 13a | X3J3/009/004 | | 5. PURE procedures | References: HPF Language Specification, Version 1.0, May 1993 | Repository Item: 28 (from B9 only - incomplete) | X3J3/009/005 | | 6. Object initialization | References: Repository Items: 1a, 1b, 22 | X3J3/009/006 | | 7. Remove conflicts with IEC 559 (IEEE 754, IEEE 854) | References: Repository Item: 30 | X3J3/009/008 | | 8. CPU_TIME intrinsic function | References: Repository Item: 12 | X3J3/009/009 | | 9. Nested WHERE | References: Repository Item: 36 | X3J3/009/010 | | 10. User-defined functions in declarations | References: Repository Item: 31 (from B9 only - incomplete) | X3J3/009/011 | | 11. Specification of further obsolescent features | References: Repository Items: 3, 3a | N917 | X3J3/009/007 | | 12. Exception handling | References: Section F.4.1 of S8.104 (Appendix F) | Repository Items: 5, 5a, 5b, 5c | X3J3/009/012 | | 13. Allocatable components in structures | References: N931 | Repository Item: 16 | X3J3/94-269r2 | | 14. Optional generic-spec on END INTERFACE | References: N1017 | Repository Item: 39 | | 15. User-defined elemental procedures | References: X3J3/94-245r3 | Repository Item: 35 | | 16. Automatic deallocation of allocatable arrays | References: X3J3/94-270r3 | Repository Item: 40 # A2. FORALL statement # Status: Being Developed for 1995 Revision # References: Section F.2.3 of S8.104 (Appendix F) # HPF Language Specification, Version 1.0, May 1993 # Repository Items: 13, 13a # Target date for completion: March 1995 # Progress: Entered in X3J3/009 with status "X3J3 consideration in progress" # A3. FORALL construct # Status: Being Developed for 1995 Revision # References: HPF Language Specification, Version 1.0, May 1993 # Repository Item: 13a # Target date for completion: March 1995 # Progress: Entered in X3J3/009 with status "X3J3 consideration in progress" # # A4. PURE prefix on functions # Status: Being Developed for 1995 Revision # References: HPF Language Specification, Version 1.0, May 1993 # Repository Item: 28 (from B9 only - incomplete) # Target date for completion: March 1995 # Progress: Entered in X3J3/009 with status "X3J3 consideration in progress" # # A5. Add DIM parameter to MAXLOC and MINLOC intrinsic functions # Status: Being Developed for 1995 Revision # References: HPF Language Specification, Version 1.0, May 1993 # Repository Item: 29 (from B9 only - incomplete) # Target date for completion: March 1995 # Progress: Entered in X3J3/009 with status "X3J3 approved" # # B1. Object initialization # Status: Requested for 1995 Revision # References: Repository Items: 1a, 1b, 22 # Target date for completion: March 1995 # Progress: Entered in X3J3/009 with status "X3J3 consideration in progress" # # B2. Remove conflicts with IEC 559 (IEEE 754, IEEE 854) # Status: Requested for 1995 Revision # References: Repository Item: 30 (from B9 only - incomplete) # Target date for completion: # Progress: Tutorial - See N966 # # B3. Allocatable components in structures # Status: Requested for 1995 Revision # References: N931 # Repository Item: 16 # Target date for completion: # Progress: Tutorial # # B4a. Minimal and exact field width editing # Status: Requested for 1995 Revision # References: Repository Items: 9, 10 # Target date for completion: March 1995 # Progress: Minimal field width - Entered in X3J3/009 with status # "approved by X3J3" # Exact field width - No action # # B4b. Specification of further obsolescent features # Status: Requested for 1995 Revision # References: N917 # Repository Items: 3, 3a # Target date for completion: March 1995 # Progress: Entered in X3J3/009 with status "X3J3 consideration in progress" # (items agreed - edits forthcoming) # # B4c. Comments in namelist and list-directed input # Status: Requested for 1995 Revision # References: Repository Item: 4 (namelist only) # Target date for completion: March 1995 # Progress: Comments in namelist input - Entered in X3J3/009 with status # "approved by X3J3" # Comments in list-directed input - Due to a technical difficulty # X3J3 recommends this not be pursued - See N967 # # C1. CPU-time intrinsic function # Status: Being Investigated for 1995 Revision # References: Repository Item: 12 # Target date for completion: # Progress: Tutorial # # C2. KIND parameters for derived types # Status: Being Investigated for 1995 Revision # References: Repository Items: 14, 14a # Target date for completion: # Progress: Proposal # # C3. Allow some classes of user-defined functions in declarations # Status: Being Investigated for 1995 Revision # References: Repository Item: 31 (from B9 only - incomplete) # Target date for completion: # Progress: Tutorial - See N968 # # C4. Support IEC 559 conforming or similar hardware # Status: Being Investigated for 1995 Revision # References: Repository Item: 32 (from B9 only - incomplete) # Target date for completion: # Progress: Returned to WG5 with recommendation that WG5 initiate a # new work item for a binding to IEC 559 - See N966 # # C5. Exception handling # Status: Being Investigated for 1995 or 2000 Revision # References: Section F.4.1 of S8.104 (Appendix F) # Repository Items: 5, 5a, 5b, 5c # Target date for completion: # Progress: Proposal - See N969 # # C6. Object oriented programming # Status: Being investigated for 1995 Revision # References: Repository Item: 18 # Target date for completion: # Progress: Tutorial # # C7 Derived type I/O # Status: Being Investigated for 1995 Revision # References: Repository Item: 17 # Target date for completion: # Progress: Returned to WG5 with recommendation that it be deferred - # See N944 # ------------------- Contents of Repository 1 Change Initial Status of Pointers to Disassociated 1a Allow Pointer Initialization with a Target 1b Allow Initialization of Pointer Status 2 Controlling Pointer Bounds 3 Language Evolution 3a Features to be declared obsolescent in F96 4 Namelist Comments 5 Exception Handling 5a Exception Handling 5b Condition Handling 5c Exception Handling 6 Conditional Compilation 7 Block Comments 8 CONSTANT as a synonym for PARAMETER 9 Minimal Field Width Editing 10 Exact Field Width Editing 11 Aliasing Type Definitions 12 Process time from System Clock 13 FORALL statement 13a FORALL 14 Parameterised Derived Types 14a Kind Parameters for Derived Types 15 Remove name class irregularities 16 Allow ALLOCATABLE derived-type components 17 Derived Type I/O 18 Object Oriented Programming 19 Standardization of performance directives 20 Command Line Arguments and Environmental Variables 21 Bit Data Type, String 22 Implicit Initialization of Structure Components 23 Multi-threaded execution facilities 24 Remove the restriction on the maximum rank of arrays 25 Extend the semantics of the EXIT statement 26 Selecting subarrays of non-rectangular form 27 Parallel sections construct | 28 Pure User Functions and Subroutines # 28 PURE prefix on functions 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 32 Support IEC 559 conforming or similar hardware 33 Nesting of internal procedures 34 Varying length character with declared maximum | 35 User Defined Elemental Functions | 36 Nested WHERE | 37 Unsigned INTEGER Data Type | 38 Improve Interoperability between Fortran and ANSI C | 39 Optional generic-spec on END INTERFACE | 40 Automatic deallocation of allocatable arrays Number: 1 Title: Change Initial Status of Pointers to Disassociated Submitted By: DIN Fortran Working Group | Status: Accepted for 1995 Revision, with changes. # Status: For Consideration References: N779 Basic Functionality: Change the initial status of pointers from undefined to disassociated. Rationale: The varying length character string module has demonstrated the need for garbage collection - either user-supplied or processor supplied. Garbage collection is difficult, if not impossible, without automatic initialization of pointers. Pointer initialization will also improve the safety and security of programs, and it will relieve programmers of the tedium of inserting statements to initialize pointers. Estimated Impact: This affects only the pointer facility. It will not invalidate any existing programs; it will cause some overhead for compilers and possibly for program execution. Detailed Specification: History: Presented to WG5 by Wolfgang Walter at the Victoria meeting | in July, 1992. | Object initialization accepted for 1995 Revision, Aug 1994, | see X3J3/009/006. # in July, 1992. Number: 1a Title: Allow Pointer Initialization with a Target Submitted By: Germany | Status: Accepted for 1995 Revision # Status: Requested for 1995 Revision References: N902, N932 Basic Functionality: It should be possible for the F96 programmer to specify that pointers, and pointer components, are to be created with a defined initial status. Rationale: The lack of this facility has and will continue to result in code which is unnecessarily inefficient; see for example the varying string module. In most cases it will be sufficient for the user to be able to specify that the initial status be disassociated, but it would also be useful for it to be possible to specify an initial association with a specific target. The existing syntax for initialization should be used to allow a user to specify a defined initial state for pointer variables and pointer components, e.g. by extension of the notion of pointer assignment to initialization. Estimated Impact: | Detailed Specification: X3J3/009/006 # Detailed Specification: History: Requested for 1995 Revision via B9/B1 | Object initialization accepted for 1995 Revision, Aug 1994, | see X3J3/009/006. Number: 1b Title: Allow Initialization of Pointer Status Submitted by: UK | Status: Accepted for 1995 Revision # Status: Requested for 1995 Revision References: N909, N932 Basic Functionality: Allows specification of a defined initial status for pointers and pointer components. For dynamic objects, such as unsaved local variables, allocatable arrays, and allocated pointer targets, this must include every instance created at run time. Rationale: It should be possible for the F96 programmer to specify that pointers, and pointer components, are to be created with a defined initial status. The lack of this facility has and will continue to result in code which is unnecessarily inefficient; see for example the varying string module which is by no means abnormal in its design. Estimated Impact: Allows significantly more efficient execution of programs. No effect on existing programs. Small effect on compilers. Detailed Specification: This section contains a possible syntax and accompanying semantics that could be used to allow a user to specify a defined initial state for pointer variables and pointer components. It is a minimalist suggestion due originally to Jerry Wagener. It merely allows the qualifier NULLIFY to be specified along with the POINTER attribute, for example, REAL,POINTER(NULLIFY) :: pra(:,:) The semantics proposed is that such a pointer would initially be disassociated. For example, the varying-string module could use the type: TYPE VARYING_STRING CHARACTER,POINTER(NULLIFY) :: chars(:) ENDTYPE VARYING_STRING The semantics now are that whenever an object of type VARYING_STRING is created, the pointer component will be created in the disassociated state. It could be regarded as having zero length and the assignment procedure could safely check for an already allocated variable and deallocate it. The declaration type(VARYING_STRING) :: page(66) would create an array of zero-length strings. This would greatly reduce the degree of memory leakage in the example implementation. This proposal is minimalist in that it permits only setting the initial state of a pointer to be disassociated. It does not allow the pointer to be initially associated with an existing target, nor are any non-pointer components specifiable as being initially defined. If this approach is agreed by WG5, the UK is willing to provide a detailed specification. | Detailed Specification: X3J3/009/006 | History: Requested for 1995 Revision via B9/B1 | Object initialization accepted for 1995 Revision, Aug 1994, | see X3J3/009/006. 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 # Status: Requested for 1995 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: 3a Title: Features to be declared obsolescent in F96 Submitted by: UK (also requested by Russia) | Status: Accepted for 1995 Revision, with changes. # Status: Requested for 1995 Revision References: N909, N919 Basic Functionality: Definition of the following features of Fortran 90 to be obsolescent: - Computed GOTO - Alternate ENTRY - Statement Functions - DATA statements among the executables - Assumed character length functions - Old fixed form source - Assumed size arrays - Pointers in storage associated contexts - The .EQ., .LT., etc. forms for the relational operators Rationale: The UK believes that the features specified in the list are essentially redundant and their use in new code is generally undesirable. It 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. There would be majority support in the UK for declaring all storage association based facilities obsolescent at this stage, particularly given the inherent inefficiency of the mechanism in any distributed memory MIMD or SIMD multi-processor environment, but the UK refrains from proposing this at this point on the grounds that this would almost certainly be controversial. Estimated Impact: No effect on standard-conforming programs until publication of Fortran 2001. Small effect (detection of new obsolescent features) on compilers. Detailed Specification: Extension to Appendix B2 and corresponding changes to fonts in the body of the standard. History: Requested for 1995 Revision via B9/B4.2 | Language evolution items accepted for 1995 Revision, | Aug 1994, see X3J3/009/007. Number: 4 Title: Namelist Comments Submitted By: Charles Lawson | Status: Accepted for 1995 Revision # Status: Requested for 1995 Revision References: N840 Basic Functionality: Allow comments in namelist input data Rationale: This is an extension provided by several vendors. Users find it very helpful when input data files are large. Estimated Impact: Affects namelist input processing only. No impact on existing programs. Requires small change in runtime I/O library. Detailed Specification: History: Request from the Fortran public, received by Convenor September 30, 1992 Requested for 1995 Revision via B9/B4.3 | Accepted for 1995 Revision, Aug 1994, see X3J3/009/002. Number: 5 Title: Exception Handling Submitted By: IFIP WG 2.5 | Status: Accepted for 1995 Revision # Status: Being investigated for 1995 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 # Detailed Specification: History: Request received by Convenor from IFIP WG 2.5, October 14, 1992 Request for investigation via B9/C5 | Accepted for 1995 Revision, Aug 1994, see X3J3/94-258r4. Number: 5a Title: Exception Handling Submitted By: Germany | Status: Accepted for 1995 Revision # Status: Being investigated for 1995 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 # Detailed Specification: History: Request for investigation via B9/C5 | Accepted for 1995 Revision, Aug 1994, see X3J3/94-258r4. Number: 5b Title: Condition Handling Submitted By: US | Status: Accepted for 1995 Revision, with changes. # Status: Being investigated for 1995 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 | Accepted for 1995 Revision, Aug 1994, see X3J3/94-258r4. Number: 5c Title: Exception Handling Submitted by: UK (also requested by Russia) | Status: Accepted for 1995 Revision # Status: Being investigated for 1995 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 | Accepted for 1995 Revision, Aug 1994, see X3J3/94-258r4. Number: 6 Title: Conditional Compilation Submitted By: US (also requested by Russia) Status: For Consideration 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. 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: 8 Title: CONSTANT as a synonym for PARAMETER Submitted by: Canadian Fortran Working Group | Status: Rejected # Status: For Consideration Reference: N901 Basic Functionality: No new functionality is added. However, an important, common and *meaningful* usage of terminology will be permitted. Rationale: The word PARAMETER was (in the opinion of many) a mistake as a choice of term for what is really a named constant. Much as it would be nice, we can not remove it from the language now, but we can see no reason that the word CONSTANT can not be allowed in Fortran as a synonym for PARAMETER. Textual changes are needed in the document, but we believe that is all. Perhaps the only argument against allowing declarations of the form Integer, CONSTANT :: MaxUpdates = 7 is that it is a redundant form. We feel however that such a argument is very weak, for the language is already full of redundancy. The small amount of redundancy introduced is more than offset by the improved clarity of such declarations. It should be pointed out that this usage would even be much more consistent with the definitions in the standard itself in section 2.4.3.1.2. Estimated Impact: Very little. The term CONSTANT will become an optional synonym for PARAMETER. Since it will only be allowed within declaration statements, there should be very little, if any, opportunity for conflict with existing programs. Although we are not writing with a background as compiler writers, it would not seem to be difficult for a compiler to recognize a synonym for a construct which it is already able to handle. Detailed Specification: The easiest way to modify the document to reflect this addition would be to replace PARAMETER by CONSTANT in R503 and to add is PARAMETER after the first line of R503. In the remainder of 5.1, replace PARAMETER by CONSTANT 5 times (up to the beginning of 5.1.1). Also, add the statement "The attr-spec PARAMETER is entirely equivalent to the attr-spec CONSTANT." as a new first paragraph of 5.1.2.1. In the title and in the existing text of 5.1.2.1, change PARAMETER to CONSTANT 10 times. To be complete, the change also requires that 5.2.10 be changed to replace PARAMETER by CONSTANT 11 times (including in the title). Also, then change "parameter-stmt" to "constant-stmt" in R538 and add a second line to R538 "or PARAMETER ( named-constant-def-list)". A new paragraph should be added immediately after R539: "The PARAMETER statement is entirely equivalent to the CONSTANT statement." All occurrences of "parameter-stmt" in 2.1 (and elsewhere in the document" should be changed to "constant-stmt". Another highly desirable edit would be to replace every occurrence of "type-param-value" to "type-const-value". This global change could be done by an editor with an electronic copy and global search capabilities. An electronic check for other references to constants as 'parameters' should also be performed. | History: Rejected by WG5, August 1994. # History: Number: 9 Title: Minimal Field Width Editing Submitted by: Canadian Fortran Working Group | Status: Accepted for 1995 Revision # Status: Requested for 1995 Revision References: N901 Basic Functionality: This allows values to be output which occupy just as many character spaces as are actually required. Rationale: One weakness of Fortran formatted output is that there is no way to have a numeric value use "as few locations as needed". It would seem that an easy solution exists with a slight extension to the language. To be more specific, it would often be convenient to have a *single* format statement for which the output would be This is case 1; ain't that nice This is case 999; have a nice day In the first case, 1 character is enough to represent the numeric value, but in the second, 3 are needed. To output this with one format statement, current Fortran would require write(6,99) 'This is case ', 1,"; ain't that nice" write(6,99) 'This is case ',999,'; have a nice day' 99 format (a,i3,a) In order to be able to print the value 999, the format 'i3' is needed, but then the output would have some "unaesthetic" spaces in it: This is case 1; ain't that nice This is case 999; have a nice day Although these line up nicely, if just the first is printed, as in This is case 1; ain't that nice it is clear that one might prefer not to have the spaces. The proposal is to allow a "width" designator of "0", which, informally, would be interpreted to mean: "use as small a field width as possible". It would permit the following, which we do not believe is now possible in Fortran (at least not without considerable effort). write(6,99) 'This is case ', 1,"; ain't that nice" write(6,99) 'This is case ',999,'; have a nice day' 99 format (a,' ',i0,a) Now the output would indeed be: This is case 1; ain't that nice This is case 999; have a nice day For integers, there is no question of what is meant by the minimum field width needed; clearly leading zeroes are not used, and a sign is included only if required. For reals, a couple of examples should indicate the intent: x = -6.5; y = 7.0; z = 86.554433 write(6,98) x,x; write(6,98) y,y; write(6,98) z,z 98 format ('We have f = ',f8.4,& ', or f is ' ,f0.4, '| THE END') The output of these three write statements would be We have f = -6.5000, or f is -6.5| THE END We have f = 7.0000, or f is 7.| THE END We have f = 86.5544, or f is 86.5544| THE END The required field width would include sufficient characters for the sign (if required) and decimal point, along with characters for the integer part of the number with no leading zeroes or blanks, plus the number of characters specified by the "d" part of the "w.d" designator, with any trailing printing zeroes removed. By trailing printing zeroes, we mean any zeroes which would actually be printed if the "d" field were used per se. Estimated Impact: As is seen below, this has little impact on the text of the standard itself. It should have no impact on existing standard conforming programs since the proposal is to allow an editing field width which is not currently legal. There will be some impact for compiler writers, for they will have to first determine the field width requirements for a data item before inserting it into the output stream, which is a change from the current situation where the position of the data value could be determined before looking at its value. It is not thought however that this would be difficult. It is related to the decision which they must make anyway in the case of G formatting. Detailed Specification: What follows is a proposal for consideration of "w=0" as a permissible field width. The justification is above. Here we given required changes to the document. We believe these suffice. After R1009, change the first constraint to read "The value for e must be positive." After that first constraint, add a new second constraint: "The value of 0 for w is permitted only for output editing." In 10.5.1, add a sentence to the end of item (5): "The field width is never considered to be exceeded if the width is given as zero, as in rule (6)." In 10.5.1, add a sixth point: (6) On output, the value of w may be zero. This indicates that the field width is to be the minimum required to represent the value of the corresponding list item. In other words, when w is specified to be zero, the effect is, in every case, as if a positive value had been specified for w which was the smallest value which would permit the number to be output without any leading or trailing blanks, and with any insignificant leading and/or trailing 0 characters in the output representation removed. History: It has been noted that this is an existing extension in some compilers. It is not known how common that is. Requested for 1995 Revision via B9/B4.1 | Accepted for 1995 Revision, Aug 1994, see X3J3/009/003. Number: 10 Title: Exact Field Width Editing Submitted by: Canadian Fortran Working Group | Status: Rejected. # Status: Requested for 1995 Revision References: N901 Basic Functionality: This allows the programmer to control whether data items are to be output which occupy exactly the number of character spaces that are specified, or whether they should be output using at least the number of positions specified. The implication is that in the first case, the current Fortran 77/90 interpretation of output formatting is preserved, and if the value will not fit in the designated space, all character positions are replaced by the character "*". In the second case, the implication is that if the value will not fit, then the number of spaces allowed for this data item in the output record may be increased to the smallest number which will accommodate the data value. There will be two control edit descriptors, EX (Exact) to specify the first interpretation, and LT (Least) for the second. Rationale: One weakness of Fortran formatted output is that there is no way to have a numeric value use "as few locations as needed"; this is discussed in the rationale for the proposal "Minimal Field Width Editing". Furthermore, it is sometimes very inconvenient to have perfectly valid output be replaced by "*"'s, especially when F editing is desired, just because the value happens to be a bit too large. This proposal should be considered as complementary to the Minimal Field Width Proposal. One advantage here is that EX and LT would function like BN and BZ; they would act as a toggle for the method of treating all subsequent data items in a format list. The second advantage is that one can still provide a field width, which is only to be exceeded if necessary. Estimated Impact: As is seen below, this has little impact on the text of the standard itself. It should have no impact on existing standard conforming programs since the proposal is to allow editing descriptors which are not currently legal. Furthermore, where there is a choice, the default case implements current practice. There will be some impact for compiler writers, for they will have to first determine the field width requirements for a data item before inserting it into the output stream, which is a change from the current situation where the position of the data value could be determined before looking at its value. It is not thought however that this would be difficult. This is the same as for the Minimal Field Width Proposal. Detailed Specification: What follows is a proposal for consideration of control edit descriptors EX and LT. The justification is above. Here we given required changes to the document. We believe these suffice. This is written on the presumption that the proposal "Minimum Field Width Editing" has been incorporated into the document. To R1010, add "or width-desc" and after R1015, add a new syntax rule R1015a width-desc is EX or LT In 10.5.1, add a sentence to the end of item (5): "The field width is also never considered to be exceeded if the width-desc LT is in effect, as in rule (7)". In 10.5.1, add a seventh point: (7) On output, least width editing may be in effect. This indicates that the field width is to be the smaller of the given width w and the minimum required to represent the value of the corresponding list item. In other words, when the number of characters produced exceeds the specified field width, and least width editing is in effect, the result is, in every case, as if a value of zero had been specified for w. If minimal width editing is not in effect, then, if the numbers of characters produced exceeds the field width, the output is as prescribed in rule (5). Add a new section 10.6.7 "EX and LT editing": The EX and LT edit descriptors may be used to control the form of the output produced when the number of characters produced to represent a data value exceeds the field width specified for that data item. The appearance of EX or LT in a format statement affects all subsequent output edit descriptors I, B, O, Z, F, E, EN, ES, G or D. However, specification of EX does not affect any format item with a specified field width of 0. Furthermore, LT and EX do not have any effect on input data editing. The effect of edit descriptors LT and EX is as given in 10.5.1. At the beginning of execution of a formatted output statement to a file connected by an OPEN statement, least (LT) or exact (EX) width formatting is in effect, depending on the value of the WIDTH = specifier (9.3.4.11) currently in effect for the unit; an internal file or a file not connected with an OPEN statement is treated as if it were opened with WIDTH = 'EXACT'. Add to R905: or WIDTH = scalar-default-char-expr Add a new section 9.3.4.11 "WIDTH= specifier in the OPEN statement": The scalar-default-char-expr must evaluate to EXACT or LEAST. The WIDTH = specifier is permitted only for a file being opened for formatted output. If EXACT is specified, then the data items are output with exact field width editing (10.5.1); if LEAST is specified, then the data items are output with least field width editing in effect. History: Requested for 1995 Revision via B9/B4.1 | Rejected, August 1994. Reason: (see N992) too similar to the | feature for minimal field width editing. 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: 12 Title: Process time from System Clock Submitted by: Canadian Fortran Working Group | Status: Accepted for 1995 Revision, with changes # Status: Being investigated for 1995 Revision References: N901 Basic Functionality: This will allow a user to get the amount of time used by a single process in a multitasking environment. Rationale: The current system clock routine is very limited in its applicability since it does not address the issue of multitasking. Estimated Impact: The impact for users would be significant. This would remove one of the few remaining machine dependencies in Fortran codes, since there would no longer be any need to call a system dependent routine to get the 'running time' of a process. Most systems provide this capability, so it should not be difficult for compiler writers to implement this. Detailed Specification:Revise the description of the intrinsic routine System_Clock, as follows. (Note: in some sense, the functionality being added is different in nature to that of the existing routine; therefore, an alternative may be to introduce a separate intrinsic routine. However, the existing routine provides a convenient to make this proposal.) In the definition, add a new argument "PROCESS" after COUNT-MAX. Add ", PROCESS" to the list of optional arguments. Modify the description: Change "from a real-time clock" to "from a real-time or process clock". Add the statements: "If the optional argument "PROCESS" is present and has the value 'true', then the values returned for COUNT, COUNT_RATE and COUNT_MAX refer to a clock which is related only to the execution of the current Fortran program. Otherwise, the values returned are those for the basic processor clock." Before "Example", add PROCESS (optional) must be scalar and of type default logical. It is an INTENT(IN) argument. After the last line of the example, add "Furthermore, for a program using precisely one quarter of the time on a multiprocessing system with the same processor clock, the call Call System_Clock (COUNT=C, PROCESS=.true.) will return the value 21599. History: Request for investigation via B9/C1 | Accepted (with changes) for 1995 Revision, Aug 1994, | see X3J3/009/009. Number: 13 Title: FORALL statement Submitted By: UK, Germany | Status: Accepted for 1995 Revision # Status: Being Developed for 1995 Revision References: S8.104, section F.2.3, June 1987 High Performance Fortran Language Specification, Version 1.0, May 1993, section 4.1. N902, N916, N909 Basic Functionality: Allows array assignments to be specified in terms of a set of array element and array section assignments, as in HPF. Rationale: The UK believes it was a mistake that this statement was left out of F90, and would wish for it to be included in F96. Although there is some sympathy for the view that a FORALL construct as well is desirable, the consensus opinion of the UK is that only the statement form should be included at this stage. Germany notes that the official HPF subset of the current HPF draft does not include the FORALL construct. It is recommended that the proposals in this area of the HPF group be considered as the prime starting point for the design. However, given the deficiencies of the current HPF draft, this should be a guide only. Estimated Impact: No effect on existing standard-conforming programs. Possible effect on HPFF programs. Small effect on processors. Detailed Specification: As in HPF History: Accepted for 1995 Revision via B9/A2 Target for Completion: March 1995 | Progress: Accepted for 1995 Revision, Aug 1994, see X3J3/009/004. # Progress: Entered in X3J3/009 with status "X3J3 consideration in progress" Number: 13a Title: FORALL Submitted By: US (also requested by Russia) | Status: Accepted for 1995 Revision # Status: Being Developed for 1995 Revision References: Section F.2.3 of S8.104 (Appendix F) N900, N916, N919 Basic Functionality: Add a FORALL statement or construct, or both, to perform array assignments in terms of a set of array element or array section assignments. Rationale: A FORALL statement or construct would complement the array assignments and WHERE constructs and statements in Fortran 90. It permits a more general class of array sections to be manipulated, and it is often easier to understand since the operation is expressed in terms of individual array elements in a syntax suggestive of a corresponding mathematical notation. Estimated Impact: No impact on programs conforming to Fortran 90; however, note that an implementation incompatible with that of HPF could cause significant problems for many Fortran users. Detailed Specification: The array elements or sections and their corresponding right-hand-side expressions are determined by a set of subscript names (with a scope of the FORALL statement or construct), each of which takes on, in no predetermined order, the set of values determined by a triplet notation similar to that used for a subscript-triplet. An optional mask, consisting of a scalar logical expression which also depends on the FORALL subscripts, may be specified to control the execution of the individual sub-assignments. The order in which the individual element or section assignments are made is not defined; however, all expressions on the right hand side corresponding to true values of the mask expression (if present) should be evaluated before any assignments are made to the left hand side. No element of the array may be assigned a value more than once. See the FORALL construct of HPF. History: Accepted for 1995 Revision via B9/A2 and A3 Target for Completion: March 1995 | Progress: Accepted for 1995 Revision, Aug 1994, see X3J3/009/004. # Progress: Entered in X3J3/009 with status "X3J3 consideration in progress" Number: 14 Title: Parameterised Derived Types Submitted By: Germany | Status: Being investigated for 2000 Revision # Status: Being investigated for 1995 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. Number: 14a Title: Kind Parameters for Derived Types Submitted by: UK | Status: Being investigated for 2000 Revision # Status: Being investigated for 1995 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. 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: Accepted for 1995 Revision # Status: Requested for 1995 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 | Accepted for 1995 Revision, Aug 1994, see X3J3/94-269r2. Number: 17 Title: Derived Type I/O Submitted By: Germany, UK | Status: Being investigated for 2000 Revision # Status: Being investigated for 1995 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 # Status: Being investigated for 1995 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: 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: 22 Title: Implicit Initialization of Structure Components Submitted By: Germany | Status: Accepted for 1995 Revision # Status: Requested for 1995 Revision References: N902r, N932 Basic Functionality: We need to allow the initialization syntax to be specified for derived type components with the interpretation that this provides an initial value for the component when a structure of the type is created, regardless of whether the structure was created by declaration or by allocation. Rationale: If components were defined as initialized in the type definition, the relevant components of the structure would have to be given the initial value. If the same initialization syntax were specified for intrinsic types, each variable of this type would have to be supplied with the initial value. Estimated Impact: Detailed Specification: History: Requested for 1995 Revision via B9/B1 | Object initialization accepted for 1995 Revision, Aug 1994, | see X3J3/009/006. 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: 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: 28 | Title: Pure User Functions and Subroutines # Title: PURE prefix on functions | Submitted By: US # Submitted By: WG5 | Status: Accepted for 1995 Revision # Status: Being Developed for 1995 Revision References: HPF Language Specification, Version 1.0, May 1993 | X3J3/004/025 | Basic Functionality: Add support for user written "pure" functions and | subroutines. This facilitates use of the block FORALL construct, by | helping compilers parallelize the execution of FORALL. | This requirement partially overlaps with another requirement, user | defined elemental functions. # Basic Functionality: | Rationale: Requested by other Fortran related standards groups (HPFF). # Rationale: | Estimated Impact: None # Estimated Impact: | Detailed Specification: X3J3/009/005 # Detailed Specification: History: Accepted for 1995 revision via B9/A4 Target Date for Completion: March 1995 | Progress: Accepted for 1995 Revision, Aug 1994, see X3J3/009/005. # Progress: Entered in X3J3/009 with status "X3J3 consideration in progress" | Number: 29 Title: Add DIM parameter to MAXLOC and MINLOC intrinsic functions Submitted By: WG5 | Status: Accepted for 1995 Revision # Status: Being Developed for 1995 Revision References: HPF Language Specification, Version 1.0, May 1993 Basic Functionality: Rationale: Estimated Impact: Detailed Specification: History: Accepted for 1995 revision via B9/A5 Target Date for Completion: March 1995 | Progress: Accepted for 1995 Revision, Aug 1994, see X3J3/009/001. # Progress: Entered in X3J3/009 with status "X3J3 approved" Number: 30 Title: Remove conflicts with IEC 559 (IEEE 754, IEEE 854) Submitted By: WG5 | Status: Accepted for 1995 Revision # Status: Requested for 1995 Revision References: Basic Functionality: Rationale: Estimated Impact: Detailed Specification: History: Requested for 1995 revision via B9/B2 | Accepted for 1995 Revision, Aug 1994, see X3J3/009/008. Number: 31 Title: Allow some classes of user-defined functions in declarations Submitted By: WG5 | Status: Accepted for 1995 Revision # Status: Being Investigated for 1995 Revision References: Basic Functionality: Rationale: Estimated Impact: Detailed Specification: History: Being investigated via B9/C3 | Accepted for 1995 Revision, Aug 1994, see X3J3/009/011. Number: 32 | Title: Binding to IEEE 754 # Title: Support IEC 559 conforming or similar hardware | Submitted By: US # Submitted By: WG5 | Status: Being Investigated for 2000 Revision # Status: Being Investigated for 1995 Revision | References: X3J3/004/028 # References: | Basic Functionality: Bind Fortran to the IEEE standard for Binary | Floating Point Arithmetic, ANSI/IEEE 754-1985. # Basic Functionality: | 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. # Rationale: | 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. # Estimated 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.) # Detailed Specification: | 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) # History: Being investigated via B9/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: 35 | | Title: User Defined Elemental Functions | | Submitted By: US | | Status: Requested for 1995 Revision | | References: X3J3/94-245r3 | | Basic Functionality: The ability to define elemental functions. | | Rationale: Elemental functions are useful on parallel processors, | where each element of an array can be given to an individual processor | with user defined code to execute. User defined elemental functions | allow users to write functions which work over all ranks of arrays | without having to write a different function for each possible rank. | | Estimated Impact: No impact on existing code. | | Detailed Specification: See X3J3/94-245r3 | | History: Presented by Dick Hendrickson at the Edinburgh meeting of X3J3 | in August 1994. | | | | | Number: 36 | | Title: Nested WHERE | | Submitted By: US | | Status: Accepted for 1995 Revision | | References: High Performance Fortran, X3J3/009/010 | | Basic Functionality: Adding support for nested WHERE statements may be | desirable for expressing parallelism. | | Rationale: Facilitates extensions to Fortran environments by other | standard bodies (e.g., HPFF). | | Estimated Impact: None | | Detailed Specification: See X3J3/009/010 | | History: Accepted for 1995 Revision, Aug 1994, see X3J3/009/010. | | | | | | 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: For Consideration | | 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. | | | | | | | Number: 39 | | Title: Optional generic-spec on END INTERFACE | | Submitted By: WG5 | | Status: Accepted for 1995 Revision | | References: N1017, N1050 | | Basic Functionality: Allow the optional use of a generic specification | on the END INTERFACE statement. | | Rationale: Most of the END statements in Fortran 90 can include an optional | identifier. The END INTERFACE statement is one of the few END | statements that can not have an identifier on it (the END WHERE statement | is the only other case). By allowing the END INTERFACE statement | of a generic interface to optionally indicate the generic | specification, the language becomes more consistent. | | Allowing this feature can improve the visual impact of code. | Consider the following code fragment: | INTERFACE GEN | FUNCTION F() | END FUNCTION F | FUNCTION S(I) | END FUNCTION S | END INTERFACE GEN | If there were more numerous specific interfaces within the interface | block then the appearance of GEN on the END INTERFACE reaffirms | which generic interface is being defined. | | Many people already assume that it is part of the language. Repeatedly | questions have been submitted to the X3J3 /interp subgroup that | contain "END INTERFACE name" as part of the example. | | Estimated Impact: No impact on existing code. Small change for | processors. | | Detailed Specification: See N1017 | | History: Accepted for 1995 Revision, Aug 1994, see N1017. | | | | Number: 40 | | Title: Automatic deallocation of allocatable arrays | | Submitted By: WG5 | | Status: Accepted for 1995 Revision | | References: X3J3/94-270r3. | | Basic Functionality: Require automatic deallocation of unSAVEd allocatable | objects on scope exit. | | Rationale: Automatic deallocation of allocatable arrays (including allocatable | array components) provides the user with a safe method of creating opaque data | types of variable size which do not leak memory. It also removes the burden | of manual storage deallocation both for simple allocatable arrays and for | allocatable components of non-opaque types. | The "undefined" allocation status of Fortran 90 meant that an | allocatable array could easily get into a state where it could not be further | used in any way whatsoever, it could not be allocated, deallocated, | referenced, defined, or even used as the argument to the ALLOCATED function. | Removal of this status provides the user with a safe way of handling | allocatable arrays which he does not desire to be SAVEd, permitting use of the | ALLOCATED intrinsic function to discover the current allocation status of the | array at any time. | | Estimated Impact: | | Detailed Specification: See X3J3/94-270r3 | | History: Accepted for 1995 Revision, Aug 1994. | | | ----- End Included Message -----