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

, but KIND selection is only supported for radix 10. | This is a source for unportable code because many implementations | and applications are based on radix 2: There is no simple portable | way to select an INTEGER kind with 31 bits -- SELECTED_INT_KIND(9) | guarantees only 30 bits, and SELECTED_INT_KIND(10) needs 34 and | likely returns a too large KIND. Similar for REAL. | | 3. The character intrinsic procedures use the notion of "the number of | charcters in the collating sequence associated with the specific kind | type parameter". This has a role similar to the constants defined | in 13.7.1 for numeric models, but no inquiry function is provided to | inquire about . This inhibits portable use of the character intrinsic | procedures. | | Estimated Impact: | Low. Specifying 1 requires some thought on the representation of | LOGICAL (there is no model for LOGICAL). For 2, an optional argument | RADIX to SELCTED_INT_KIND and SELECTED_REAL_KIND must be defined to | allow changing "decimal precision" to "RADIX precision". Implementing | 3 is straightforward. | The specifications 13.14.39, 13.14.94 and 13.14.95 need rewording. | This addition does not affect portable F95 programs (except for the | possibility of overloaded user procedures with these characteristics). | | Detailed Specification: | To be provided. | | History: none | | ---------------------------------------------------------------------- | | Number: 58 | | Title: Array Components of Array Structures | | Submitted by: US | | Status: For Consideration | | References: Section F.2.1 of S8.104 Appendix F (aka X3J3/119-LJM-1) | | Basic Functionality: Treat array structures containing array components as | higher-rank array objects; that is, remove the restriction against structure | references containing more than one part-ref with non-zero rank. | Interpret the shape of such a reference to be (/ C, P /), where P is the shape | of the parent and C is the shape of the component. | | Rationale: | | Estimated Impact: | | Detailed Specification: | | History: Submitted by USTAG after X3J3 meeting #137 {May-1996} | | ---------------------------------------------------------------------- | | Number: 59 | | Title: Intrinsic and User-defined Specific and Generic Names | | Submitted by: US | | Status: For Consideration | | References: | | Basic Functionality: Permit the specific name of a user-defined procedure to be | passed as an actual argument even if it is the same as the generic name, just | as is permitted in Fortran 77 and Fortran 90 for intrinsic functions. | | FORTRAN 77 introduced the concept of generic and specific names for intrinsic | functions. It requires that wherever an intrinsic function name is passed as | an actual argument it must be in the form of the specific name. Thus, when ABS | is passed as an actual argument, it is interpreted as the specific, rather than | the generic, name. | | Fortran 90 allows users also to define generic and specific names. Once again, | only specific names may be passed as actual arguments. However, the penultimate | constraint in 12.4.1 [172/7f] categorically prohibits a generic name being | passed as an actual argument. Thus, if a generic name is identical to a | specific name, it cannot be passed at all as it is interpreted as a generic | name. As an example | | subroutine test | INTERFACE f | FUNCTION f(x) | REAL f, x | END function f | END INTERFACE | call thing (f) ! f is generic (as well as specific) | ! and cannot be used | end subroutine test | | is illegal. Thus, there is an inconsistency between the interpretation of | F77-style generic names and of f90-style generic names. | | The code above should be made legal by interpreting the use of 'f' in the | actual argument to be a specific name. A possible solution is to add 'unless | it is also a specific name' at the end of the penultimate constraint of 12.4.1 | [172/8] in Fortran 90. | | Rationale: Inconsistencies in the language breach the Principle of Least | Surprise. | | Estimated Impact: | | Detailed Specification: | | History: Submitted by USTAG after X3J3 meeting #137 {May-1996} | | ---------------------------------------------------------------------- | | Number: 60 | | Title: Pointer Association Classes | | Submitted by: US | | Status: For Consideration | | References: | | Basic Functionality: Provide a mechanism to limit the targets to which a | pointer may point or the pointers which may point to a target. | | Rationale: Use of this mechanism would reduce the optimization impact of using | pointers. | | Estimated Impact: Textual modifications appear to be moderate in size, but | widely distributed and hard to get right. A conforming processor could | accommodate the declarations simply by treating names appearing in a POINTER | attribute as though they were declared with the TARGET attribute, but using | this information intelligently would be much harder. | | Detailed Specification: Extend POINTER attribute to allow specification of the | targets with which the pointer can be associated. Extend the TARGET attribute | to allow specification of the pointers which may be associated with it. A | pointer association is allowed if either pointer or the target identifies the | possibility. | | (May wish to also allow some derived permissions: If P allowed to | point to Q and Q allowed to point to R, then P allowed to point to | R. If P allowed to point to R and Q allowed to point to R, then P | allowed to point to Q or vice versa. However, P allowed to point to | Q and P allowed to point to R is _not_ sufficient for Q to be | allowed to point to R.) | | History: Submitted by USTAG after X3J3 meeting #137 {May-1996} | | ---------------------------------------------------------------------- | | Number: 61 | | Title: Generic COUNT_RATE Argument for SYSTEM_CLOCK | | Submitted by: US | | Status: For Consideration | | References: ISO/IEC 1539:1993 (E) 13.13.104 | X3J3/94-006r1 Interpretation 000132 | X3J3/94-160 | | Basic Functionality: The data type of the COUNT_RATE argument to the | SYSTEM_CLOCK intrinsic subroutine should be changed from default INTEGER to | generic REAL. | | Rationale: Currently the Fortran standard requires that all three arguments to | SYSTEM_CLOCK be of type default INTEGER. While the INTEGER data type is | acceptable for COUNT and COUNT_MAX, it causes serious accuracy problems for the | COUNT_RATE argument. This is most likely an error in the existing standard | which should be corrected. This error unnecessarily restricts the available | precision. | | The processor clocks of many machines, most notably the clocks of MS-DOS PCs, | have significant fractional components in their clock rates. On Intel (MS-DOS | PC) machines, the clock ticks 18.2037 times per second. Requiring COUNT_RATE | to be INTEGER causes considerable loss of accuracy for such machines. | | Interpretation 132 attempted to resolve this problem but it is at best a barely | tolerable quick fix. As currently defined, interpretation 132 poses severe | portability problems, even from one compiler to another on the same machine. | In the Intel case, the interpretation allowed all three of these practices: | | 1. Increment COUNT by 1 every .05495 seconds but return a | COUNT_RATE of 18. | | 2. Increment COUNT by 10 every .05495 seconds and return a | COUNT_RATE of 182. | | 3. Increment COUNT by a variable amount every .05495 | seconds and return a COUNT_RATE of 100. | | All three of these practices are, at best, counter-intuitive and not | the behavior an ordinary programmer would expect. At worst, the are | downright deceptive. Most programmers expect COUNT_RATE to be a very | close approximation to the actual system clock rate. | | One of the most attractive features of Fortran is that it is generally | intuitive and straightforward. There are relatively few traps and | "gotchas" which cause problems for programmers who have less than | expert level of ability. This characteristic is in sharp contrast to | other languages, especially C and C++. In order to encourage the | continued popularity of Fortran, X3J3 should eliminate such problems | whenever possible. | | Estimated Impact: Minimal. Changing the data type to generic REAL would | invalidate some existing code but changing the code should not require very | much effort. | | Detailed Specification: | | History: Submitted by USTAG after X3J3 meeting #137 {May-1996} | | ------------------------------------------------------------------------------- | | Number: 62 | | Title: Interval arithmetic support | | Submitted by: US | | Status: For Consideration | | References: | | Basic Functionality: Provide datatypes and intrinsic operators for interval | arithmetic. | | Interval arithmetic provides a way for users to have confidence in the quality | of their computations, facilitates the solution of entire classes of | numerically difficult problems, and simplifies the algorithm choice. | | Rationale: It is not possible for user coded implementations to achieve | performance levels that can be obtained if the compilation system is intimately | aware of the interval arithmetic. | | As more and more complex decisions are made on the basis of computer | simulation, the need to quantify the precision and accuracy of computations | increases, as well as the cost of being wrong. | | Estimated Impact: Submitter says: Doing work on this, or any other feature, | means we won't be working on something else. It is hard to quantify the precise | impact at this time. Aside from considerable work at the standard writing | level, implementation is fairly complicated (especially if one is serious about | getting good performance on many existing hardware designs). | | Detailed Specification: Some text may be provided later. There is some | experience in (alas no longer supported) CDC FORTRAN compiler(s). In addition a | dialect of Pascal from the University of Karlshule. | | In principle, it should be possible to define a standard module which defines a | new family of REAL datatypes and operators. It is not currently possible for | users to extend I/O to new types; it would be highly desirable to extend the | I/O system to handle these INTERVAL REAL types and their special needs. | | History: Submitted by USTAG after X3J3 meeting #137 {May-1996} | | ------------------------------------------------------------------------------- | | Number: 63 | | Title: STREAM I/O | | Submitted by: US | | Status: For Consideration | | References: | | Basic Functionality: A extension to the OPEN statement to enable "byte stream" | I/O on that logical unit. | | Rationale: C-style "byte stream" has become a de facto standard far beyond the | direct scope of the C environment. In a scientific application it is not | surprising to have a sensor feeding a stream of data to a processor which in | turn feeds the results over a heterogeneous network for additional processing. | Fortran record structure provides the user with an obstacle to overcome in this | scenario (the processors may not have the same record conventions (even when | the CPU architecture is the same), etc.) | | A special specifier on the OPEN statement to provide (formatted or unformatted, | direct or sequential) stream I/O. It is intended that such I/O be compatible | with that processors equivalent C environment. | | Estimated Impact: | | Detailed Specification: A possible implementation might look like: | | OPEN (unit=5, file = "stdin", form = "formatted", style = "stream") | | As there will be no record information stored, BACKSPACE will be prohibited on | this unit. There may well be other limitations. | | (Note: this is not the same as non-advancing I/O. In that case, there is a | record structure, even if the programmer only operates on a single record | during an entire run. Though the difference may be moot in some operating | environments, it may be critical in others. In addition, the extra record | information could present difficulties to other Fortran processors or to | processors other than Fortran.) | | History: Submitted by USTAG after X3J3 meeting #137 {May-1996} | | ----------------------------------------------------------------------------- | | Number: 63a | | Title: Binary stream I/O | | Submitted by: US | | Status: For Consideration | | References: | | Basic Functionality: Implement a binary stream I/O facility to allow writing | and reading to/from unformatted files without any internal structure. | | Rationale: Traditionally, Fortran I/O facilities have been record oriented. | Fortran 90 has introduced a non advancing I/O facility that provides for | reading and writing partial records in formatted sequential files. | | However, there is a category of files that are definitely not record oriented. | This category is called "binary stream files". These files are merely | constituted of a continuous sequence of storage units, without any internal | structure. Stream files are prevalent in many operating systems such as Unix, | DOS, Windows and OS/2. Also, there are "industry-standard" file formats that | are not record oriented, such as GIF and TIFF formats for digital images. | | Accessing stream files with standard Fortran I/O facilities is often difficult: | unformatted sequential access may fail because the file contains no record | delimiters. Using unformatted direct access is also awkward since the data | cannot be accessed easily with fixed record lengths. In short, a new file | access is needed. | | Many vendors have already extended their compilers to provide this facility by | allowing "binary" or "transparent" file access methods, showing a need for | standardization. | | Estimated Impact: The new feature affects the OPEN, READ, WRITE, and INQUIRE | statements. The ENDFILE statement will acquire a new functionality. | | Implementing this feature should be very easy, since a similar functionality | is already provided as an extension by many vendors. The implementation of the | FILESIZE specifier in the INQUIRE statement shouldn't also cause problems | since virtually all operating systems provide a facility to obtain the size of | a file in bytes or words. | | Detailed Specification: only new keywords and options in OPEN, READ, WRITE, | and INQUIRE are needed. | | A binary stream file consists of a sequence of processor-dependant storage | units. These units must be the same to those used to define the record length | of an unformatted direct file. The storage units are numbered from 1 to n, n | being the last unit written. Two concepts are present in a stream file. A file | position pointer is used to locate the next storage unit to be read or | written. Following the last storage unit of the file, there is an end-of-file | marker that may physically exist or not. This marker can be checked in a READ | statement by END or IOSTAT specifiers. The file position pointer may point to | the end-of-file marker. | | Opening a binary stream file could be done by simply adding ACCESS='STREAM' in | the OPEN statement. The POSITION specifier is valid for these files. | | Binary stream I/O should work following in an hybrid fashion between | sequential and direct access. Sequential access should be done by using the | syntax of unformatted sequential READ and WRITE, except that the unit is | connected to a binary stream file. The file position pointer is moved by the | amount of data storage units transferred by each READ or WRITE statements | executed. Random access should be provided by adding a POS=location specifier | to the READ or WRITE statements. Mixed access should be allowed for the same | unit. When a WRITE statement overwrites a portion of a stream file, only the | amount of storage tranferred should replace the existing locations; the | remaining storage units should remain intact (in the contrary of conventional | unformatted sequential WRITEs). | | READ and WRITE statement with POS specifiers but with an empty I/O list merely | move the pointer inside the file. In the case of a WRITE statement, if the | position pointer is moved with the POS specifier beyond the end-of-file | marker, the gap is filled with unitialized data. | | The BACKSPACE statement should be disallowed for such files, since there is no | record delimiters. | | The ENDFILE statement is used to truncate the binary stream file | at the current file pointer position. | | New specifiers should be added to the INQUIRE statements. | | In particular, a CURRPOS specifier to obtain the current position | of the pointer, and a FILESIZE specifier that returns the amount | of units written to the file. The ACCESS specifer should also be | extended to allow ACCESS='STREAM' to be returned. | | History: Submitted by USTAG after X3J3 meeting #137 {May-1996} | | ------------------------------------------------------------------------------ | | Number: 63b | | Title: Non-advancing I/0 combined with free format | | Submitted by: Germany | | Status: For Consideration | | References: | | Basic Functionality: Allow combination between non advancing I/0 and | free I/0 format to be able to read ascii files in free I/O format. | | Rationale: Better I/O compatibility between e.g. C and Fortran 90 | | Estimated Impact: No effect on existing programs | | Detailed Specification: The requirement concerns reading ascii files in | free I/O format. | Output in software systems written to files is often organized | as a number of data, one or multiple per line. The exact format cannot | be known in advance, neither the number of data per line. Very often, | files organized in the above way have to be read by other programs. | The output format and the number of data per line are typically | unknown, especially if two independent software components are involved | in the writing and reading phases of the files. | Fortran provides free format I/O, which means that the format has | not got to be specified in advance for the reading process, and non | advancing I/O, which means that the number of dates per line need not | be known in advance. If the output now in generated by a complete | independent software component, perhaps written in C, the input phase | would have to combine non advancing I/O and free format. Fortran 90 | input does not work with combined free format and non advancing I/O. | | ---------------------------------------------------------------------- | | Number: 64 | | Title: Extend MAX, MIN, etc. to CHARACTER Data Type | | Submitted by: US | | Status: For Consideration | | References: | | Basic Functionality: Extend the intrinsic functions MAX, MIN, MAXVAL, MINVAL, | MAXLOC, and MINLOC to accept arguments of CHARACTER data type. | | Rationale: Regularity is the primary reason for this requirement. These | intrinsic functions accept arguments of two other intrinsic data types, REAL | and INTEGER. Accepting this proposal would recognize first class status of the | CHARACTER data type and would extend these functions to all intrinsic data | types for which they would make sense. | | This requirement would considerably simplify the implementation of generic sort | algorithms that are sometimes applied to CHARACTER data. | | Estimated Impact: | | Detailed Specification: | | History: Submitted by USTAG after X3J3 meeting #137 {May-1996} | | ------------------------------------------------------------------------------- | | Number: 65 | | Title: Extend Non-advancing I/O to List-Directed I/O | | Submitted by: US | | Status: For Consideration | | References: | | Basic Functionality: Permit list-directed formatting with the ADVANCE="NO" | specifier. | | Rationale: This feature adds regularity. It simplifies frequently occurring | operations where parts of an output record are generated in successive | statements by permitting it to be list-directed. It also permits input from a | single record to occur in separate statements. In this latter case, the input | might include tests based on the first part of the input data. | | Proof that this would be feasible can be found in most freshman Pascal | programs. In such programs, the most common I/O operation is equivalent to | Fortran list-directed non-advancing. | | Estimated Impact: | | Detailed Specification: | | History: Submitted by USTAG after X3J3 meeting #137 {May-1996} | | ------------------------------------------------------------------------------- | | Number: 66 | | Title: Extend Initialization of COMPLEX Variables | | Submitted by: US | | Status: For Consideration | | References: | | Basic Functionality: Permit initialization of COMPLEX constants with named | constant in either part. Alternatively, permit the intrinsic function CMPLX in | initialization expressions. | | Rationale: Applications which make extensive use of conplex numbers need | maximum flexibility to permit suitable programming style. Such applications | occur in a wide variety of fields such as electrical engineering, as seen in | the example below. | | The current standard requires | | REAL, PARAMETER :: Omega = 1.23E6 | COMPLEX :: J_Omega = (0.0, 1.23E6) | | which means that the same constant must be declared twice, once real and again | in the imaginary part of the complex constant. This could lead to inadvertent | programming errors. | | Estimated Impact: | | Detailed Specification: The first method would allow the following syntax: | | REAL, PARAMETER :: Omega = 1.23E6 | COMPLEX :: J_Omega = (0.0, Omega) | | The alternative method would allow the following syntax: | | REAL, PARAMETER :: Omega = 1.23E6 | COMPLEX :: J_Omega = CMPLX (0.0, Omega) | | History: Submitted by USTAG after X3J3 meeting #137 {May-1996} | | ------------------------------------------------------------------------------- | | Number: 67 | | Title: Lower Case Syntax Elements | | Submitted by: US | | Status: For Consideration | | References: | | Basic Functionality: A Fortran processor should recognize the use of lower case | letters in all Fortran syntax elements. This should include all keywords and | symbolic names. In all cases the use of lower case letters should be equivalent | to upper case letters except in a character context (i.e., Fortran syntax would | continue to be case insensitive). There may be a need for a second exception | as part of the functionality needed to implement interoperability with C. | | Examples in the standard should include mixed case syntax. | | Rationale: The need to restrict syntax elements to upper case letters is a | relic from the 1960s. Up until the early 1980s, some machines did not support | lower case letters in their character sets. Now, such a restriction is no | longer necessary; all platforms with a Fortran 90 processor include support for | lower case letters. | | Removing the upper case only restriction would allow programmers to write more | visually appealing code. All other major languages already support lower case | letters in their syntax elements. | | Removing this restriction would help remove the image that Fortran still has | of being a "Stone Age" relic. | | Estimated Impact: | | Detailed Specification: All that would be necessary would be to make the | appropriate edits to the text in section 3.1.1. | | History: Submitted by USTAG after X3J3 meeting #137 {May-1996} | | ------------------------------------------------------------------------------ | | Number: 68 | | Title: Any Kind of Integer for I/O Specifiers | | Submitted by: US | | Status: For Consideration | | References: | | Basic Functionality: I/O specifiers which use INTEGER data objects should be | able to use any kind of INTEGER which is defined on the processor. The current | restriction which requires the use only of default INTEGER data objects should | be removed. | | Rationale: Recent e-mail discussion brought attention to the fact that that the | Fortran 90 standard permits any kind of integer for some I/O keywords while it | requires the use of default integer data objects for other I/O keywords. This | is an unnecessary irregularity. | | Some Fortran processors use a default integer size of 4 bytes (32 bits) always | but also allow the user to specify an 8 byte (64 bit) integer data object. | Other Fortran processors also support 8 byte integers but offer the user a | choice of a default integer size of either 2 bytes or 4 bytes. On these | processors, certain large size I/O operations (i.e., those with a number of | records or a record size greater than 2.147 billion) are more difficult than | they need to be. Although workarounds are possible, they are clumsy and error | prone. | | Estimated Impact: Minimal. Many Fortran processors already support this | feature as an extension. | | Detailed Specification: Replace scalar-default-int-variable with | scalar-int-variable wherever it occurs in connection with an I/O specifier. | | History: Submitted by USTAG after X3J3 meeting #137 {May-1996} | | ------------------------------------------------------------------------------ | | Number: 69 | | Title: Permit BOZ constants in the TRANSFER function | | Submitted by: US | | Status: For Consideration | | References: | | Basic Functionality: Permit BOZ literal constants to be used in the SOURCE | argument of the TRANSFER function, either as scalar values or within array | constructors. Prohibit the use of such constants in the TRANSFER function if | they are too long to fit in any available integer representation method. | | Rationale: | | Estimated Impact: | | Detailed Specification: EDITS (based on X3J3/94-007R4): | | 1. [32:1-2] Section 4.3.1.1: Replace the paragraph beginning "In a | DATA statement..." with, | | An unsigned binary, octal, or hexadecimal literal | constant may be used as a data-stmt-constant | corresponding to an integer scalar variable in a DATA | statement (5.2.9) or in the SOURCE argument to the | TRANSFER function (13.13.110). | | 2. [32:6] Section 4.3.1.1: In the constraint following R407, after | "DATA statement" add "or in the SOURCE argument of the TRANSFER | function". | | 3. [44:40+] Section 4.5: Insert after the first line of R433, | | or boz-literal-constant | | 4. [45:5+] Section 4.5: Add the following constraints: | | Constraint: An array-constructor shall not | contain a boz-literal-constant unless | it is the actual argument corresponding to | the SOURCE dummy argument of the TRANSFER | function (13.13.110). | | Constraint: All boz-literal-constants used in an | array-constructor must explicitly | specify the same number of bits. | | 5. [271:10+] Section 13.13.110: Add the following new paragraph to | the end of the "Result Value" section: | | If SOURCE is specified as a boz-literal-constant | (4.3.1.1), or as an array-constructor containing | boz-literal-constants, these constants shall be | treated as integer values in the representation method | having the smallest value for the model parameter, | s (13.5.7), that is at least as large as the number | of bits explicitly specified in the constant. For | example, if SOURCE is specified as Z'00FF', it is treated | as 255_K16, where K16 is whatever integer kind type | parameter gives the smallest value of BIT_SIZE(0_K16) | that is greater than or equal to 16. A | boz-literal-constant specifying more bits than | allowed by any available integer representation method | shall not be used in SOURCE. | | History: Submitted by USTAG after X3J3 meeting #137 {May-1996} | | ---------------------------------------------------------------------- | | Number: 70 | | Title: "Clean up" conformance rules | | Submitted by: US | | Status: For Consideration | | References: | | Basic Functionality: Review conformance rules with an eye towards making them | more regular, easier to understand, more useful, etc. | | Rationale: The standard would be easier to understand, more useful, etc. | | Estimated Impact: Much of this could be done with only localized changes to the | document, but identifying the difference between static and dynamic | requirements in the standard might be more widespread. | | Most of this should have very limited impact on existing processors. The | obvious exception would be a requirement that processors check the correctness | of formats expressed as character constant expressions. | | Detailed Specification: Specific issues I would suggest looking at include the | following: | | o If a Fortran program uses a procedure defined by means other than | Fortran, it can still be a standard-conforming program. However, | if the vendor changes that procedure to an intrinsic procedure to | make it more efficient, the program becomes nonconforming. We | should try to treat these cases similarly. | | o If a format is written as a FORMAT statement, the processor is required | to be able to check it for correctness, but if it is written as | a CHARACTER constant, the processor is not. | | o If we should separate the concepts of a program which is standard | conforming in form (i.e., on a static basis) from whether or not | the execution of that program conforms. | | History: Submitted by USTAG after X3J3 meeting #137 {May-1996} | | ------------------------------------------------------------------------------ | | Number: 71 | | Title: Allow MERGE in constant expressions | | Submitted by: US | | Status: For Consideration | | References: | | Basic Functionality: Modify the limitations on initialization expressions in | some way that would allow the MERGE intrinsic to be used. | | Rationale: It is possible to work around the lack of MERGE, at least for | integer relations, but the result tends to be obscure in the extreme. | | Estimated Impact: The document changes will likely be difficult to formulate, | but well localized. The changes to existing processors should be similarly | localized. | | Detailed Specification: | | History: Submitted by USTAG after X3J3 meeting #137 {May-1996} | | ------------------------------------------------------------------------------ | | Number: 72 | | Title: Extend ALLOCATE to specify non-KIND type parameters | | Submitted by: US | | Status: For Consideration | | References: | | Basic Functionality: Extend the ALLOCATE statement to allow specification of | type parameters. Allow POINTER or ALLOCATABLE to be used with declaration forms | used to "assume" type parameters. | | In the current standard, this affects only the LEN parameter of the | CHARACTER type, but it would extended to parameterized derived types. | | Rationale: This should be an obvous part of parameterized derived types. E.g., | if one creates a parameterized MATRIX type, it should be obvious that one might | want an allocatable matrix for much the same reasons one wants allocatable | arrays. | | The ISO varying string module demonstrated the difficulty of having to allocate | a character array when what you really needed was a string whose length you | could control. | | Estimated Impact: | | Detailed Specification: | | CHARACTER(*), ALLOCATABLE :: C | ... | ALLOCATE ((LEN=L)C) | | History: Submitted by USTAG after X3J3 meeting #137 {May-1996} | | ------------------------------------------------------------------------------ | | Number: 73 | | Title: Named Scratch Files | | Submitted by: US | | Status: For Consideration | | References: X3J3 / 96-007r0 9.2.2.2 | | Basic Functionality: Allow the user to specify a file name if a file is opened | with STATUS="SCRATCH". | | Rationale: Fortran 90 does not allow the user to name scratch files. We should | lift this restriction. Allowing the programmer to name scratch files can be | useful, especially if the program crashes. Not allowing the programmer to name | a file in this one case is an unnecessary irregularity. since there is legacy | code which has STATUS="SCRATCH" without a FILE= specifier, the best solution is | to allow the optional use of FILE= with STATUS="SCRATCH". | | Estimated Impact: Minimal. Adding this capability should not be very difficult | to implement. | | Detailed Specification: This could be accomplished by making minor changes to | section 9.3.4. | | History: Submitted by USTAG after X3J3 meeting #137 {May-1996} | | ------------------------------------------------------------------------------ | | Number: 74 | | Title: Additional Visibility Attribute | | Submitted By: UK | | Status: For Consideration | | References: x3j3 JOR 95-004 item 033, item 043, N1144 item 18, ISO/IEC | 1539 :1991(E) Sections 4.4, 4.4.1, 4.4.2, 5.1, 5.1.2.2, 5.2.3, 11.3.1, | 11.3.2, 12.1.2.2.2 and 14.1.2.5 | | Basic Functionality: Provide a third level of accessibility, between | PRIVATE and PUBLIC, for module entities. | | Rationale: There are at least two good reasons for the proposed | orthogonal enhancement of functionality: | i) PRIVATE entities are only visible in the module in which | they are declared. Any procedure which accesses this PRIVATE | entity must reside in the same module as the definition. This | means modules may grow very large and cumbersome. | ii) Sometimes it is desirable to extend a module. Without access to | the source code this is not currently possible. | What is needed is a third visibility attribute that allows controlled | visibility to specified entities but only by modules containing a special | access clause and not by other program units or modules not containing | the clause. | | Estimated Impact: Edits will need to be made to the standard in the | areas given above although these are thought to be fairly self | contained. Current modules will still be correct but it will be | advantageous for them to be enhanced. There do not appear to be | any performance issues. | The OOP and OOF proposals may also be affected. | | Detailed Specification: | | There should be a new visibility attribute and statement denoted by the | keyword RESTRICTED which can be used in exactly the same contexts | as PRIVATE. For example, | MODULE Main | TYPE, RESTRICTED :: Vector | REAL :: x,y | END TYPE Vector | INTEGER, RESTRICTED :: Distance | INTEGER, PUBLIC :: Version | END MODULE Main | would give the type Vector and the variable Distance the RESTRICTED | attribute, and the simple statement | RESTRICTED | would make RESTRICTED the default visibility attribute. | In order to prevent accidental use/abuse of restricted entities it | must be explicitly stated that one module has a `special relationship' | with another. The proposed method enhances the USE | statement to include an ACCESS specifier which is used in an analogous way | to the existing ONLY specifier. For example, | MODULE Child | USE Main, ACCESS : Direction => Vector | USE Main, ONLY : Version | USE Other | TYPE(Direction) :: North | END MODULE Child | Here there RESTRICTED type definition (of Vector) is made visible and | the type is given an alternative name (Direction). The other restricted | entity from the module (Distance) is not visible. The PUBLIC entities | from Main or Child can be used as normal. A rewrite of R1107/8/9 is | given at the end of this document. | There are clearly a number of issues associated with this addition to | the syntax: | i) The local name of a RESTRICTED entity may appear in no other | specification statement that would cause any attribute of the entity to | be respecified. | ii) A further module, say GrandChild, can USE Child but will not | have access to the RESTRICTED entities accessed from Main unless it | accesses them directly. | iii) A RESTRICTED entity may appear in a USE statement if and only if | it has an ACCESS clause. Any RESTRICTED entities to be accessed | must be explicitly named. A RESTRICTED entity would be accessible | by only one name. | iv) More than one USE statement with an ACCESS clause may appear in a | scoping unit. | | | Syntax rule R1107 and sequence would be rewritten as follows: | R1107 use-stmt USE module-name [, rename-list] | USE module-name, ONLY: [only-list] | USE module-name, ACCESS: access-list | R1107a access restricted-generic-spec | [local-name =>] restricted-name | Constraint: Each restricted-generic-spec shall be a restricted entity in | the module. | Constraint: Each restricted-name shall be the name of a restricted entity | in the module. | Constraint: A USE statement with the ACCESS option shall appear only | in the scoping unit of a module. | A USE statement with the ACCESS option provides access only to those | restricted entities that appear as generic-specs or restricted-names in | the access-list. | | History: | | ---------------------------------------------------------------------- | | Number: 75 | | Title: Allow PUBLIC entities of PRIVATE type. | | Submitted By: UK | | Status: For Consideration | | References: IS 1539-1:1996, 4.4.1 first constraint of rules R425-R427, | 5.1 tenth constraint of rules R501-R506, | 5.2.3 last constraint of rules R522-R523. | | Basic Functionality: Remove the restrictions in the standard that require | (1) for PUBLIC module variables and parameters of derived type, that the | type is defined as PUBLIC; | (2) for components of a PUBLIC derived type definition in a module, that the | component type must be intrinsic or defined as PUBLIC; | (3) PUBLIC module functions of derived type must be of a type defined as | PUBLIC; and | (4) derived-type dummy arguments of a PUBLIC module procedure must be of a | type defined as PUBLIC. | | Rationale: These restrictions do not serve any useful purpose, they | merely add to the complexity of the language and its implementations. | There are many situations in Fortran where, through use association or | host association, the name of a type is not available in any way but | that entities of that type are visible. | Furthermore, lifting these restrictions would allow a module to | provide even more tightly controlled entities and values than are | possible with the "PUBLIC type with PRIVATE components" type. As | the user cannot create variables or other entities of a PRIVATE | type, a module can reliably provide values of its own that are | therefore protected from accidental corruption (e.g. by variables | becoming undefined). | | Estimated Impact: Small effect on standard (remove restricting text). | No anticipated effect on other suggested features. Little impact in | compilers (remove a test and error message). No significant effect on | compilation speed. No effect on execution speed. | | Detailed Specification: The following style of code now becomes possible. | TYPE,PRIVATE :: real_matrix_type | INTEGER code | END TYPE | ! | ! Because the type is PRIVATE, the user cannot create variables of this type, | ! but is limited to using the PARAMETERs we provide below. | ! | TYPE(real_matrix_type),PUBLIC :: general_matrix = real_matrix_type(1) | TYPE(real_matrix_type),PUBLIC :: upper_triangular = real_matrix_type(2) | TYPE(real_matrix_type),PUBLIC :: lower_triangular = real_matrix_type(3) | TYPE(real_matrix_type),PUBLIC :: symmetric = real_matrix_type(4) | ... | SUBROUTINE factorise(type,array,...) | TYPE(real_matrix_type),INTENT(IN) :: type | REAL,INTENT(INOUT) :: array(:,:) | ... | END SUBROUTINE | | Proposed Edits: | [39:1-3] Delete constraint. | [48:15] Delete constraint. | [58:29-31] Delete constraint. | | History: | | ---------------------------------------------------------------------- | | Number: 76 | | Title: Default I/O mode | | Submitted by: UK | | Status: For Consideration | | References: | | Basic Functionality: Allow a file to be opened with default I/O mode of | non-advancing. | | Rationale: Stream I/O, as opposed to record I/O, is increasingly used in other | fields and other languages and fits in with some programmers' mind-sets. To | allow easy specification of the method would enhance functionality with minimal | change to the language. | | Estimated Impact: No impact on existing programs, slight impact on processors. | | Detailed Specification: Add ADVANCE= as an extra connect-spec in the OPEN | statement. If a data transfer statement for formatted sequential I/O on this | unit does not have an ADVANCE= specifier, it is interpreted as if it had | the ADVANCE= specifier of the OPEN statement. Also make the corresponding | change to the INQUIRE statement. | | History: | | ---------------------------------------------------------------------- | | Number: 77 | | Title: New Special Character designations | | Submitted by: UK | | Status: For Consideration | | References: | | Basic Functionality: Additional character designations. | | Rationale: The Fortran way of writing of special, typically | non-printing, characters is inconvenient when compared to the method | used in, for example, C and Unix. | UNIX style \t (tab), \n (newline), \f (form feed) etc. symbols would | make useful additions to the standard. They could be turned on by a | compiler switch checked by a defaults routine. | | Estimated Impact: The standard makes no use of \ at present, but there | would be an effect an existing program using \ is a character string. | | Detailed Specification: | | History: | | ---------------------------------------------------------------------- | | Number: 78 | | Title: Qualifiers and Attributes for High Performance Computing with | Fortran 90 | | Submitted by: Germany | | Status: For Consideration | | References: ISO/IEC JTC1/SC22/WG5 N1186 | | Basic Functionality: Selection of qualifiers as attributes or | statements which can be understood as semantic hints of the user to | give the compiler optimization and inlining possibilities. These | qualifiers give information on relations and nonrelations between data | objects which cannot be known by the compiler. | The difference between qualifiers and directives like suggested in | Number 19 is that directives are specified for single loops and | statements, and qualifiers and attributes are defined as properties for | data objects. | | Rationale: | - Give the compiler the possibility to optimize and inline code. | - Performance improvement | | Estimated Impact: | - The qualifiers fit easily in the attribute list used for declaration | of variables. Therefore it just fits right in the Fortran 90 | declaration syntax. | - The qualifiers can also be ignored if they are meaningless on several | systems | | Detailed Specification: See N1186. | Qualifiers and attributes are suggested for the following topics | - 'Injective' Qualifier for (Index) Arrays | - Restrictions for scalar and array pointers and their relations | - Keyword to allow inlining for trivial user defined procedures | - Keyword to simplify inlining of procedures with pointer arguments | - Definition of independence of variables and arrays | - Attribute to define a variable to be local on one processor on | parallel systems | - User control of copying array arguments | - Qualifier 'noloop' for (recursive) data types | | To distinguish these qualifiers from other attributes already defined | by the standard, all qualifiers could begin with the same letters like | 'QUALIFY_' or 'CH_'. | | This list of suggestions can always be completed by others. | | | History: | | ---------------------------------------------------------------------- | | Number: 79 | | Title: Recognition of TAB characters in Fortran input | | Submitted by: Germany | | Status: For Consideration | | References: | | Basic Functionality: Recognize TAB characters in Fortran input. | | Rationale: Better I/O compatibility between e.g. C and Fortran 90. | | Estimated Impact: | | Detailed Specification: Data files generated by C programs are | impossible to be read by Fortran 90 programs if TAB characters are used | in the C output which is very common. This is because the Fortran input | does not recognize TAB characters. | | History: | | ---------------------------------------------------------------------- | | Number: 80 | | Title: Intrinsic 'size' function for derived types | | Submitted by: Germany | | Status: For Consideration | | References: | | Basic functionality: Determine the length of a user defined type in bytes. | | Rationale: Mainly needed for interfaces between Fortran 90 and other | programming languages. | | Estimated Impact: | | Detailed Specification: A common problem with interlanguage | communication of Fortran 90 and other programming languages is that the | lengths of Fortran 90 data types has to be known e.g. for using the C | malloc within a C program. | A very important example therefor is the MPI interface. For the | Fortran 90 interface of MPI, the internals of derived types have to be | known. Apart from the condition that derived type components have a | sequence in the memory (which can be achieved by the Fortran 90 | SEQUENCE statement ), the length of a derived type is required. | Another example requireing a kind of a 'size' function for derived | types is RSYST. RSYST is a data base written in Fortran 77. For the | development of interfaces to different programming languageslike | Fortran 90, C, and C++, the sizes of user defined derived types have to | be known. | As there are no dynamic derived types in Fortran 90 this should not be | a real problem. The 'size' function should return the size of the | derived type in bytes. | | History: | | ---------------------------------------------------------------------- | | Number: 81 | | Title: Instrinsic 'sort' for arrays of intrinsic type | | Submitted by: Germany | | Status: For Consideration | | References: | | Basic functionality: Sorting arrays of any instrinsic type | | Rationale: Sorting routines are very often used in all different | applications. Better performance will be achieved by using optimized | intrinsic sorting algorithms. | | Estimated Impact: | | Detailed Specification: | | History: | | ---------------------------------------------------------------------- | | Number: 82 | | Title: Intrinsic function 'fft' - Fast Fourier Transformation | | Submitted by: Germany | | Status: For Consideration | | References: | | Basic functionality: Fast Fourier transforms for 1D, 2D, and 3D. | | Rationale: Optimized versions of Fast Fourier transforms | | Estimated Impact: | | Detailed Specification: | | History: | | ---------------------------------------------------------------------- | | | Number: 83 | | Title: Performance Problem: Allocation and Deallocation | | Submitted by: Germany | | Status: For Consideration | | References: | | Basic functionality: Improvement of timings of allocation and | deallocation steps | | Rationale: | | Estimated Impact: | | Detailed Specification: Dynamic memory allocation is | a performance problem in any programming language. Using the 'allocate' | statement in Fortran is not problematic if only a few objects are | allocated. But for some applications it is very typical to allocate a | lot of small data objects like list elements of linked lists e.g. in | selfadaptive grid generating algorithms. If grids are refined, new | elements like triangles, rectangles, or similar, have to be created, if | grids are recoarsed, old elements have to be deleted. | At compile time it is known which kind of data types are declared | within the program. Therefore the compiler knows a lot about the data | types and their sizes in advance which could be used somehow in the | allocation step. | It is imaginable that the compiler could build up longer lists of these | objects of each data type which turns up in the program. Each time a | new instance of a fixed size is needed, it could be taken out of this | preallocated list, which makes the access much faster because the | operating system is not anymore involved. Normally operating systems | preallocate pages, assuming all items having variable sizes. The | advantage of Fortran 90 compared to C is that the compiler knows | exactly what data type is allocated. As long as no array is allocated | the size of the data type is always known by the compiler. | In the compiling step it is already known how many list items at least | are needed. At least the first list items could be taken out of the | list. It will end up in ordinary allocation of course, if the list of | objects is used up. But at least some allocation steps could be | fastened. | | History: | | ---------------------------------------------------------------------- | | Number: 84 | | Title: Overloading possibility for Pointer assignment | | Submitted by: Germany | | Status: For Consideration | | References: | | Basic Functionality: enable overloading of the pointer assignment | | Rationale: Using pointers and especially pointer | assignments in large application often causes problems with managing | the targets. A target which has been explicitly allocated has got to | be destroyed if no pointer is related with the target anymore. In | large systems it is not possible to count the links to the target in | the background, which means, without an extra counter variable. | | Estimated Impact: | | Detailed Specification: Extend the interface statement to the form | interface assignment(=>) | | History: | | ---------------------------------------------------------------------- | | Number: 85 | | Title : Operators for more than two arguments | | Submitted by: Germany | | Status: For Consideration | | References: | | Basic Functionality: Definition of operators for more than two arguments. | | Rationale: Give the user the possibility to define operators | - for more than two arguments | - in a more natural way | | Estimated Impact : | | Detailed Specification: It would be very helpful for a user to be able | to define bracket operators which can take more thanone argument and | define their functionality. | Examples showing the use of bracket operators and how they could | be defined: | 1. Creation of a matrix out of a set of vectors | real,dimension(nmax) :: v1,v2,v3,v4,v5 | real,dimension(nmax,mmax) :: AA,BB | ... | AA = .[. v1,v2,v3,v4,v5 .]. !* first five columns of the matrix | AA = .left_[. v1,v2,v3,v4,v5 .right_]. | AA = .left_bracket. v1,v2,v3,v4,v5 .right_bracket. | BB = .{. v1,v2,v3 .}. !* first three rows of the matrix | 2. Scalar product | .<. v1, v2 .>. | 3. Lee brackets | .<. A, B.>. | 4. Tensors | a .[. x,y,z .]. | | History: | | ---------------------------------------------------------------------- | | Number: 86 | | Title: Operation System Support | | Submitted by: Germany | | Status: For Consideration | | References: | | Basic Functionality: Standardized operating system calls to make | programs portable. | | Rationale: In future there will be two main operating systems which are | UNIX and Windows NT. Operating system support at least for these two is | required. | | Estimated Impact: Many systems already provide interfaces to system | instructionsat least for languages like Fortran 77 and C and will | probably provide them for Fortran 90 in the future, but using them | would require changes within the program as soon as the platform is | changed. | | Detailed Specification: A statement like | call SYSTEM(string) | would cause its character argument to be given to | the shell as input as if the string had been typed at a terminal. | The current process waits until the shell has completed. | | History: | | ---------------------------------------------------------------------- | | Number: 87 | | Title: Requirement for Cleaner & Producer in Fortran 90 | | Submitted by: Germany | | Status: For Consideration | | References: ISO/IEC JTC1/SC22/WG5 N1187 | | Basic Functionality: A Fortran 90 cleaner is used to destroy data when | it's not needed anymore. A Fortran 90 producer is used to optimize | memory usage and to suppress time consuming allocation-deallocation | mechanisms. | | Rationale: | | Estimated Impact: | | Detailed Specification: See ISO/IEC JTC1/SC22/WG5 N1187. | A Fortran 90 cleaner is necessary to destroy data when it's not | needed anymore. A cleaner is implicitly called for each variable of | user defined type and for each pointer variable and array pointer after | the end of its scope. Each allocation of an object must have a | corresponding deallocation of the object for which the cleaner is | responsible. | The main functionality of a producer in Fortran 90 is efficient memory | allocation of objects by using already allocated storage if possible. | This also avoids copies to and from temporary variables where not | necessary. It is not a constructor in the C++ sense. | | History: | | ---------------------------------------------------------------------- | | Number: 88 | | Title: Class inheritance and dynamic binding polymorphism | | Submitted by: France | | Status: For Consideration | | References: | N1188 | S. Barbey, M. Kempe and A. Strohmeier, "Object-Oriented Programming | with Ada 9X", http://lglwww.epfl.ch/Ada/9X/OOP-Ada9X.html | | Basic Functionality: We propose to supplement Fortran with two object- | oriented mechanisms: class inheritance and dynamic binding polymorphism. | The proposed extensions are borrowed from Ada 95 with a syntax more | compatible with the Fortran culture. | | Rationale: Object orientation is required to transfer information in a | consistent way between components of large software projects. Technological | objects can be mapped into Fortran-2000 objects and transferred from parts | of a large software to others. An object in Fortran-2000 is simply an | extensible derived type with its information hidden using a 'PRIVATE' | attribute. This information is reached through methods, i.e. public | procedures belonging to the same module. | | Estimated Impact: The number of extensions is kept as small as possible in | order to speed-up the Fortran-2000 compiler development and to avoid | complexifying the language. Dynamic binding polymorphism will be | implemented using the dispaching mechanism of Ada-95 and will solve many | problems associated with the strong typing character of Fortran-90. | Inheritance and dispaching will be implemented using only two new | statements (INHERIT and CLASS) and with the introduction of class | transformation functions. | | Detailed Specifications: see N1188 | | History: | | ---------------------------------------------------------------------- | | Number: 89 | | Title: Constructors and destructors | | Submitted by: France | | Status: For Consideration | | References: | | Basic Functionality: We propose to supplement the ALLOCATE statement | with a "CONSTRUCTOR" capability and to supplement the DEALLOCATE | statement with a "DESTRUCTOR" capability. | | Rationale: Fortran-90 already have the capability to define user-defined | types and to dynamically allocate/free them with the ALLOCATE and | DEALLOCATE statements. In some cases, these user-defined types may | contains allocatable components, pointers or instances variables. A | CONSTRUCTOR mechanism is proposed to give more flexibility in defining | the initial status of such a user-defined type. Similarly, a DESTRUCTOR | mechanism is proposed to perform a clean deallocation of this type (e.g., | to avoid memory leakage). | | Estimated Impact: This functionality will bring powerful capabilities to | Fortran-2000, with only a small addition in term of syntax. There should | be no overhead in cases where this functionnality is not used. | | Detailed Specification: | | 1. The CONSTRUCTOR statement | | The CONSTRUCTOR statement define a subroutine with the ELEMENTAL attribute | which is called automatically after the ALLOCATE statement to initialize the | allocated quantity (or EACH component of the allocated quantity if the | quantity is an array). The elemental subroutine may have optional arguments | which translate into key-word entries of the ALLOCATE statement. The | CONSTRUCTOR statement may only appear in a MODULE. | | Consider the following example: | MODULE OBJ_PACK | PRIVATE | PUBLIC :: CHAR_OBJ,... | TYPE CHAR_OBJ | PRIVATE | INTEGER :: NTABLE | CHARACTER(LEN=1),POINTER,DIMENSION(:) :: PNEXT | END TYPE CHAR_OBJ | INTERFACE CONSTRUCTOR() | MODULE PROCEDURE SUB00 | END INTERFACE | ! | ELEMENTAL SUBROUTINE SUB00(AA,LENGT) | ! This is an elemental subroutine used as constructor. | TYPE(CHAR_OBJ) :: AA | INTEGER,OPTIONAL :: LENGT | IF(PRESENT(LENGT)) THEN | AA%NTABLE=LENGT | ALLOCATE(AA%PNEXT(LENGT)) | AA%PNEXT=' ' | ELSE | AA%NTABLE=0 | ENDIF | END SUBROUTINE SUB00 | ! | ... | END MODULE OBJ_PACK | | This module can be subsequently used from within a code to allocate | type CHAR_OBJ scalar or array quantities with some initial properties. | For example: | | USE OBJ_PACK | TYPE(CHAR_OBJ),DIMENSION(:),POINTER :: STRING | ... | ALLOCATE(STRING(10),LENGT=5) | | will allocate an array containing 10 elements of type CHAR_OBJ. Each | element will contain a preallocated character*1 array of size 5 | containing blank characters. | | 2. The DESTRUCTOR statement | | The DESTRUCTOR statement define a subroutine with the ELEMENTAL attribute | which is called automatically before the DEALLOCATE statement to clean the | allocated quantity (or EACH component of the allocated quantity if the | quantity is an array). The DESTRUCTOR statement may only appear in a MODULE. | | Consider the following example: | | MODULE OBJ_PACK | PRIVATE | PUBLIC :: CHAR_OBJ,... | TYPE CHAR_OBJ | PRIVATE | INTEGER :: NTABLE | CHARACTER(LEN=1),POINTER,DIMENSION(:) :: PNEXT | END TYPE CHAR_OBJ | INTERFACE CONSTRUCTOR() | MODULE PROCEDURE SUB00 | END INTERFACE | INTERFACE DESTRUCTOR() | MODULE PROCEDURE SUB11 | END INTERFACE | ! | ELEMENTAL SUBROUTINE SUB11(AA) | ! This is an elemental subroutine used as destructor. | TYPE(CHAR_OBJ) :: AA | IF(AA%NTABLE.GT.0) DEALLOCATE(AA%PNEXT) | END SUBROUTINE SUB11 | ! | ... | END MODULE OBJ_PACK | | This capability is required in the preceding example to avoid memory | leakage after the DEALLOCATE statement: | | USE OBJ_PACK | TYPE(CHAR_OBJ),DIMENSION(:),POINTER :: STRING | ... | ALLOCATE(STRING(10),LENGT=5) | DEALLOCATE(STRING) | | Here, the DEALLOCATE statement will free the preallocated character*1 | array of size 5 which is embedded in each element of the STRING array. | Without this destructor, memory leakage would occurs. | | ---------------------------------------------------------------------- | | Number: 90 | | Title: Four new elemental intrinsic functions: TRUNCATE, ROUND, IBCHNG, ICOUNT | | Submitted by: France | | Status: For Consideration | | References: | | Basic Functionality: | TRUNCATE (X,N) truncates X within N digits; | ROUND (X,N) rounds X within N digits; | IBCHNG (I,POS) reverses the bit at position POS in I; | ICOUNT(I) counts the number of bit with the value 1 present in I . | | Rationale: These functions may be useful in various applications. | | Estimated impact: None (on existing programs, apart a name conflict with an | another existing IBCHNG function in an user program). | | Detailed Specification: | | TRUNCATE(X,N) truncates X (integer or real numbers) within N digits. | The result is arithmeticaly true is X is integer. If X is real, the | result value (in base 10) is the nearest number close to the true | mathematicaly truncated value (this result value is the same as the | result obtained by an appropriate formatted output). If N is negative, | no action is done. | Examples: TRUNCATE(1254,2) is 1200. TRUNCATE(1.2512,3) is 1.25. | | ROUND(X,N) rounds X (integer or real numbers) within N digits. The | result is arithmeticaly true is X is integer or HUGE(X), with the sign | of X, if the result exceeds the range of the processor. If X is real, | the result value (in base 10) is the nearest number close to the true | mathematicaly rounded value (this result value is the same as the | result obtained by an appropriate formatted output) or HUGE(X), with | the sign of X, if the result exceeds the range of the processor. If N | is negative, no action is done. | Examples: ROUND(1254,2) is 1300. ROUND(1.24712,3) is 1.25. | | IBCHNG(I,POS) reverses the bit at position POS in integer I. | Example: IBCHNG(12,2) is 8. | | ICOUNT(I) counts the number of bit with the value 1 in I . | Example: ICOUNT(12) is 2 | | History: | | ---------------------------------------------------------------------- | | Number: 91 | | Title: PATTERN= in bit manipulation functions such as IBCLR, IBSET, IBCHNG | | Submitted by: France | | Status: For Consideration | | References: | | Basic Functionality: Using this keyword, it will be possible to apply | the functions IBCLR, IBSET, IBCHNG for a set of bit positions. | | Rationale: With the existig functions IBCLR and IBSET (and the new one | that we propose: IBCHNG), it is not possible to apply these functions | for a set of bit positions since if the actual existing argument POS is | array valued, depending either X is scalar, the result is conformable | with POS, or X is array valued and must be conformable with POS but the | result is not obtained in applaying POS to each element of X. | | Estimated impact: None (on existing programs) | | Detailed Specification: | | With the array-valued keyword PATTERN=, which is incompatible | with the keyword POS=, allow to apply the functions IBSET, IBCLR and | the (new one) IBCHNG to the I (either scalar or array valued) for | each value of , rank one array of default integers. | If FONC is either IBSET, IBCLR or IBCHNG, J = FONC(I,Pattern=A) is | equivalent to: | J = I | Do ind = LBOUND(A), UBOUND(A) | J = FONC(I,POS=A(ind)) | End Do | | Examples: IBSET( (/ 12,6 /) , Pattern=(/ 0,4 /) ) is (/ 29,23 /) | whereas IBSET( (/ 12,6 /) , Pos=(/ 0,4 /) ) will be (/ 13,22 /) | IBCLR( (/ 28,22,15 /) , Pattern=(/ 4,2 /) ) is (/ 8,2,11 /) | whereas IBCLR( (/ 28,22,15 /) , Pos=(/ 4,2 /) ) is in error | | History: | | ---------------------------------------------------------------------- | | Number: 92 | | Title: Reserved words | | Submitted by: France | | Status: For Consideration | | References: | | Basic Functionality: Let us declare as obsolete the use of keywords and | other words (for instance, the newer keywords) of Fortran as | identifiers. A such use will be flaged as warnings by the compilers | (during a fixed time, to be determined). | | Rationale: Such a thing will be very useful not only for compiler | writers but also for programmers. | | Estimated Impact: VERY STRONG. It is the reason why we propose to | inform the user by a warning during a few revisions of the standard, | say 10 years or more, BUT this will be done. | | Detailed Specification: For each occurrence of a word of the language | (statement, function or subroutine name, keywords ...) as a (user | defined) name, the compiler must flag (either with the use | of a compiler option or by default) this use by a warning. | | History: | | ---------------------------------------------------------------------- | | Number: 93 | | Title: New keywords READ_EOR, READ_EOF, WRITE_EOR (?), WRITE_EOF (?) in | INQUIRE statements | | Submitted by: France | | Status: For Consideration | | References: | | Basic Functionality: A way to obtain, for a given I/O unit or for a | given file, the various IOSTATUS codes returned by the processor for | the conditions End_Of_Record or End_Of_File associated with READ or | WRITE (?) actions. | | Rationale: In fact, the standard does not give the exact values of the | status codes returned by the processor for such conditions. Only their | sign (-) is determined with the restriction that the value associated | with EOR must be different from the one associated with EOF. Thus, | these values are processor dependent. By this present requirement, we | propose a way to obtain for a given processor, its real values. Its | seems that new keywords in the INQUIRE statement is the most natural | choice in view of Fortran use of this statement. | | Estimated Impact: None (on existing programs) | | Detailed Specification: For a given I/O unit (use of INQUIRE by | keyword UNIT= ) or for a given (connected) file (use of INQUIRE by | keyword FILE= ), the use of keyword READ_EOR = ios returns in the | default integer variable ios the real value of IOSTAT as returned in a | End_Of_Record condition that may be occur in a READ action for this | logical unit or for this file. In fact, this real value may depend on | the kind of devices (e.g. keyboard, tape device, disk ....). The same | applies for READ_EOF keyword, and, if necessary, for WRITE_EOR and | WRITE_EOF for WRITE actions. | | History: Already proposed by France for 1539-2 standard on Varying Length | Character Strings. | | ---------------------------------------------------------------------- | | Number: 94 | | Title: New keywords IS_EOR and IS_EOF in INQUIRE, READ and WRITE statements | | Submitted by: France | | Status: For Consideration | | References: | | Basic Functionality: A way to obtain, for a given I/O unit or a given | file, the certainty that the processor has really encountered an | End_Of_Record condition or an End_Of_File condition during the | associated READ or WRITE statements or by a separate test with INQUIRE | statement. | | Rationale: Without the knowledge of the the real IOSTAT code value, | allows the user to be informed of the exact kind of End_Of_something | condition that has occured. | | Estimated Impact: None (on existing programs) | | Detailed Specification: In READ, WRITE or INQUIRE statements, the | keyword IS_EOR = log returns in the default logical variable log the | value .TRUE. if the error that has occured can be considered as a | End_Of_Record condition and .FALSE. otherwise. The same for keyword | IS_EOF concerning the End_Of_File conditions. | | History: | | ---------------------------------------------------------------------- | | Number: 95 | | Title: New keywords DEFAULT_READ and DEFAULT_WRITE in INQUIRE statement | | Submitted by: France | | Status: For Consideration | | References: | | Basic Functionality: A way to obtain the logical unit number | associated, for a given processor, with the default read unit or the | default write unit. After this, the number can be used freely to | (re)direct I/O to a given logical unit (previously connected by an OPEN | statement) or to the default I/O device. | | Rationale: In fact, the standard does not give any fixed values for | the default logical units used by the processor. Hence, it appears | impossible to (re)direct some I/O to the default device in using only | I/O statements. This can be done only with tests and duplication of I/O | code, first time for one (or more) logical unit(s) previously connected | by an appropriate OPEN and callable by the logical unit number and the | second time only for the case of default device. Compare this very | simple example (for demonstration only): | ! to write data in a file but from time to time also on display | If (MOD(n_record,10)== 0) Then | Write(Unit=my_file,FMT=my_format) my_data | Write(*,FMT=my_format) my_data | Else | Write(Unit=my_file,FMT=my_format) my_data | End If | with this one, which will become possible with this requirement: | INQUIRE ( DEFAULT_WRITE = display ) | ...... | Write(UNIT=my_file,FMT=my_format) my_data | If (MOD(n_record,10)==0) Write(Unit=display,FMT=my_format) my_data | Also, with this logical unit number, it becomes possible to modify the | characteristics of the default devices, for example, for displaying 132 | characters on an appropriate display ..... by the correct OPEN | statement, OR, more simply, to know the default characteristics of | these default devices by an INQUIRE statement. | | Estimated Impact: None (on existing programs) | | Detailed Specification: In INQUIRE statement, the use of keyword | DEFAULT_READ = nunit returns in the default integer variable nunit the | logical unit number that corresponds to the default input unit for this | processor. The same with keyword DEFAULT_WRITE for the default output | device. After that, this number can be used freely to (re)direct I/O | to the default I/O device (see example in the Rationale section). | Remark: On many computers, the value returned by DEFAULT_READ= may be | 0 or 5 and for DEFAULT_WRITE= 1 or 6 ..... | A supplementary syntax, using OPEN statement, would be: | OPEN ( Unit=nunit , Default_Read , .... ) | or | OPEN ( Unit=nunit , Default_Write , .... ) | to allow a user-defined I/O unit number nunit for the default input or | output device. | | History: | | ---------------------------------------------------------------------- | | Number: 96 | | Title: Consider an array as a single object; give POINTER attribute to | array valued function results | | Submitted by: France | | Status: For Consideration | | References: | | Basic Functionality: Possibility to consider an array as a single whole | object. | | Rationale: It appears that the present standard does not allow | expressions such as MAXLOC(X(:))(1) or RESHAPE(X,(/n,n/))(:,n). | It would be very interesting and useful to enforce the consideration of | an array as a single whole object, by the use, for example, of | parenthesis as in usual mathematical notation. It also avoids the | copying of the result of many functions into temporary local arrays. | Hence, we could write: | index = (MAXLOC(X(:))(1) | (but see also F95) or | Y = (RESHAPE(X ,(/n,n/)))(:,n) | With the POINTER attribute affected to MAXLOC, it becomes possible to | write statement such as: | P => MAXLOC( X(:) ) ; index = P(1) | | Estimated Impact: None (on existing programs) | | Detailed Specification: To enforce this consideration of a given array | (for instance, as a result of an array valued function) use of | parenthesis (as in usual mathematical expressions). The POINTER | attribute will be affected to the intrinsic array-valued | transformational functions as defined by the standard. | | History: | | ---------------------------------------------------------------------- | | Number: 97 | | Title: New transformational functions: POSITION and LOCATION | | Submitted by: France | | Status: For Consideration | | References: | | Basic Functionality: These functions convert the location of an element | in an array, defined as its set of subscripts, into its position in the | array-element order. | | Rationale: This allows the user to manipulate array-addresses (position | or location) in a safe way and in the spirit of Fortran 90. | | Estimated Impact: None (on existing programs) | | Detailed Specification: | POSITION ( [Array=] X , [Script=] IX ) | LOCATION ( [Array=] X , [Pos=] n ) | Arguments: X is an array, n is a default integer (the ``position'') | and IX is a rank-one array of default integers (the``location''). | Constraint: The size of IX is equal to the rank of X and, conversely, | Values: POSITION(X,IX) returns the ``position'' in the array-element | order, of the element X(IX(1),....,IX(k)), where k is the rank of X | and, thus, the size of IX ; It is a default integer. | LOCATION(X,n) is a rank-one array and its size is equal to | the rank of the array X and gives the ``location'' of the | element of X whose ``position'' is n. It is an array of | default integers. | LOCATION(X,n) is the inverse function of POSITION i.e. whatever IX | (with legal values) LOCATION(X,POSITION(IX)) === IX and whatever n | (between 1 and Size(X)) POSITION(X,LOCATION(X,n)) === n | Examples: If X is a rank one array, | LOCATION(X,n) === (/ n + LBOUND(X,Dim=1) - 1 /) | POSITION(X,(/n/)) === n - LBOUND(X,Dim=1) + 1 | If Y is a rank two array, | LOCATION(X,n) === & | n-(n/Size(X,Dim=1))*Size(X,Dim=1)+Lbound(X,Dim=1)-1 , & | n/Size(X,Dim=1)+Lbound(X,Dim=2) /) | | History: | | ---------------------------------------------------------------------- | | Number: 98 | | Title: New functions to handle arrays: SCRIPT and SCALAR | | Submitted by: France | | Status: For Consideration | | References: | | Basic Functionality: | | SCRIPT(X,IX) allows us to use the elements of IX i.e. IX(1),...,IX(k) | where k is the size of IX (and thus also the rank of X) for referencing | an element of the rank-k array X namely | SCRIPT(X,IX) === X( IX(1) , . . . , IX(k) ). | | SCALAR (X,n) references the n-th element of array X according to the | array-element order. | | Rationale: A very useful feature of the function SCRIPT is to allow the | use of the result of some location function (e.g. MAXLOC, MINLOC) | directly in other array statement. For example, we cannot use | directly the result of MAXLOC to reference an element (i.e. | X(MAXLOC(X)) is illegal when the rank of X is different to 1). Here, is | an example that it would be very desirable: | Integer, Dimension(2), Parameter :: & | DX = (/1,0/) , & ! for derivation along x-axis | DY = (/0,1/) ! for derivation along y-axis | Integer, Dimension(2) :: IF ! no yet reserved keywords .. | Real, Dimension(nx,ny) :: F ! to represent a function | ...... | IF = MAXLOC(F) | max_f = SCRIPT(F,IF) ! i.e. MAXVAL(F) | max_f_on_x = MAX( SCRIPT(F,IF-DX), SCRIPT(F,IF+DX) ) | max_f_on_y = MAX( SCRIPT(F,IF-DY), SCRIPT(F,IF+DY) ) | grad_f_on_x = max_f - max_f_on_x ! gradiant on x | grad_f_on_y = max_f - max_f_on_y ! gradiant on y | ....... | | The function SCALAR may be considered as redundant with the two other | functions SCRIPT and LOCATION since SCALAR(X,n) is | SCRIPT( X , LOCATION(X,n) ) but, for symmetry reasons, we consider that | it must be included. Also we can note that SCRIPT(X,IX) is | SCALAR( X , POSITION(X,IX) ). | | | Estimated Impact: None (on existing programs) | | Detailed Specification: | | SCRIPT(X,IX) references the elements X( IX(1) , . . . , IX(k) ) of the | array X where k is the rank of X . | Arguments: X is an array and IX is an array of default integer. | Constaint: IX is an rank-one array of default integers. its size (k) | must be equals to the rank of X | Value: A scalar, equals to X( IX(1) , ... , IX(k) ) | Examples: If X is a rank one array: SCRIPT(X,IX)) === X(IX(1)) | is a scalar and, thus, is different to X(IX) which is a array. | | SCALAR ( X [[,Pos=] , n ] ) | Arguments: X is an array and n is a default integer. When the | argument n is not present, its default value is 1 | Constraint: 1 <= n <= SIZE(X) | Examples: When X is an array of size 1 (but eventually, of any rank), | SCALAR(X) is the value of the (only) element of this array. For | instance, we can write: ix = SCALAR(MAXLOC(Y)) where Y is a rank one | array. Note that in F95 for this example, it will be better to write: | ix = MAXLOC(Y,Dim=1) | Let Y defined by: | Real, Dimension(10,10) :: Y | valid expressions are: | x = SCALAR(Y,1) | z = SCALAR(Y,10) | | History: | | ---------------------------------------------------------------------- | | Number: 99 | | Title: Handling of error messages | | Submitted by: France | | Status: For Consideration | | References: | | Basic Functionality: Use of a available system-function that returns, | for any error code available for the processor, the error message (as | generated by the system) in a character string. | | Estimated Impact: None (on existing programs) | | Detailed Specification: Character(Len=*) ERROR_MESSAGE (ieor,operation) | where ieor is an error code (as generated by the processor) operation | is a character string that defines the operation under consideration. | The result is the corresponding error message. | | This can be implemented in a module with a standard defined name | and available for each processor. | | Example: Write(*,*) ERROR_MESSAGE (ior,'READ') | | History: | | ---------------------------------------------------------------------- | | Number: 100 | | Title: New INTENT attribute: COPY_IN | | Submitted by: France | | Status: For Consideration | | References: F90 Standard, 5.1.2.3, 12.5.2.9 | | Basic Functionality: Ensure that the entity associated with an | argument, otherwise with INTENT (IN) attribute, is passed to the | procedure through a mechanism that ensures that modifications to the | actual argument outside of the scope of the procedure are not | reflected. The two following constructs would then be equivalent: | INTERFACE | SUBROUTINE SUB (A) | REAL, INTENT (IN) :: A | END | END INTERFACE | ...... | CALL SUB ((A)) | | and | INTERFACE | SUBROUTINE SUB (A) | REAL, INTENT (COPY_IN) :: A | END | END INTERFACE | ...... | CALL SUB (A) | | Rationale: When writing library subroutines, it is not always possible | to encapsulate them, since one cannot assume that actual arguments are | not going to be modified outside of the scope of the procedure. This is | the case, for instance, when the procedure calls a user-procedure | passed as one of its arguments, and that this user-procedure modifies | via global access the actual value of another argument. This problem | can presently only be avoided by a change in the calling sequence, so, | in order to ease encapsulation, we suggest that the symetrical facility | be provided for the receiving sequence. | | Estimated Impact: Whether this will affect other language features and mean | that wide-ranging edits to the standard will be needed: Very limited. | Whether it will be hard to implement in compilers: Easy, since already | implemented as CALL SUB ((A)) | Whether it will slow compilation: Unlikely. | Whether it will slow program execution: Only if used unnecessarily, and | for some implementations. | | Detailed Specification: The INTENT (COPY_IN) attribute specifies that | the dummy argument is a copy of the actual argument of the invoking | scoping unit, that retains the value that it has at the time of | invocation. It must not be redefined or become undefined during the | execution of the procedure. | | History: | | ---------------------------------------------------------------------- | | Number: 101 | | Title: New keyword NOCOPY= for functions TRANSFER and RESHAPE | | Submitted by: France | | Status: For Consideration | | References: | | Basic Functionality: With this keyword and a value .TRUE. i.e. | NOCOPY = .TRUE. in the functions TRANSFER or RESHAPE, the action will | be done without copy-in / copy-out of the argument. | | Rationale: | | Estimated Impact: | | Detailed Specification: | | History: | | ---------------------------------------------------------------------- | | Number: 102 | | Title: Primitive graphic facilities in Fortran | | Submitted by: Canadian Standards Organization. | | Status: For consideration. | | References: | | Basic Functionality: A capability for performing primitive graphic | operations, such as conversion back and forth between alphanumeric and | graphic mode, selection of pixel density and colour range, location of | points on the display surface by the program and a mouse, and the output | of pixel sets and straight lines on the display surface. The additional | capability proposed would be the minimum required to permit Fortran to | produce a reasonable range of graphics but no more, because the | standard-conforming Fortran user already has the capability of producing | the higher level graphic operations. | | Rationale: Many Fortran users are not sophisticated with respect to | computer use. This is particularly true in engineering offices, where the | capability for using graphics would be a great asset. This fact has | induced many such persons to use non-standard-conforming Basic, where they | would have been better served by standard-conforming Fortran if it had a | graphics capability. We suspect that a graphics capability in | standard-conforming Fortran has been avoided in the past for the following | reasons: | (1) Technical difficulties, no longer a substantial problem. | (2) The fact that many members of standards committees have sufficient | computer sophistication that for them the implementation of graphics by | non-standard means is not a problem. I am attempting to speak for another | large class of Fortran users who are relatively unsophisticated in | computer use but need the graphics capability. | | Estimated Impact: Should not affect other language features. Will add | slightly to the cost of developing compilers but could increase compiler | sales. Will not slow down compilation or execution appreciably if | compilers are properly written. | | Detailed Specification: None at the present time. We can provide a much | more detailed specification if requested to do so. | | History: