ISO/IEC JTC1/SC22/WG5-N705 To: WG5 From: Lawrie Schonfelder Subject: The Future Evolution of Fortran _______________________________________________________________________________ General Principles 1. A major revision of Fortran 90 should not be started now. A period of time should be allowed for implementations to appear before a new revision of the language is begun. To start a full scale revision before the ink is dry on this one would send the wrong signals to both users and suppliers alike. 2. We should work for the next few years through the "corrigendum" and "addendum" processes. WG5 should identify a small number of areas where either clarification of the existing standard is necessary, (corrigendum), or where a specific addition to the language is required, (addendum). Subgroups, possibly based on National Body technical committees, should be assigned tasks associated with the production of such corrigenda and addenda. 3. We should become more active in looking at work outside the narrow confines of the Fortran standard world to identify those areas which are relevant to Fortran, its development and its users. For example, the possible impact of the language independent standards should be carefully considered, and if necessary addenda initiated to specify what additional Fortran specific constraints might be needed for conformance with both Fortran 90 and the CLI standards (CLIA-common Language Independent Arithmetic already exists, CLID-common Language Independent Datatypes is very advanced and CLIP common Language Independent Procedure Interfaces is being drafted). We should ensure that: a) These standards are not in direct conflict with Fortran b) These standards can be incorporated reasonably into a "Fortran standards profile". 4. We should seek to actively review and participate in the work on bindings into Fortran 90. There are major binding projects under way in a number of areas. The main ones would appear to be in graphics (GKS, PHIGS, etc.) databases (SQL etc.), and POSIX. We should be prepared to give guidance to these groups on how Fortran 90 bindings might be done (effective use of MODULE/USE and generic procedures, for instance) and to carefully review any binding proposals at an early stage. Subgroups should be established for this purpose. 5. We should strongly constrain the production of addenda to employing the extensibility properties of Fortran 90. (The Varying-string module standard is a good paradigm). We should only sanction the production of addenda which change or extend the essential syntax and semantics of the language where the required functionality cannot easily be provided within the existing language. For example, parameterisation of derived-types is an extension that requires additional syntax. Also adding multi-tasking or parallel processing capabilities is likely to require new syntax; support for, say, extended precision/range arithmetic would not. 6. A revision of ISO/IEC1 1539:1991 should be contemplated in about 1996. This revision should be accomplished by the incorporation of any corrigenda and relevant addenda in the revised standard. An open ended wholesale revision should not be undertaken. Obsolescent feature could be removed at this stage and further such features identified. Specific Proposals 7. Currently we already have one active work item, the Varying-string Module Standard. The work on this needs more active participation of a larger number of individuals and National Bodies. This is likely to be initiated by the public review processing that would be caused by a ballot to register the current draft as a CD. 8. We should set up procedures to enable the maintenance of a corrigendum working document to include the inevitable collection of clarifications and corrections to ISO/IEC 1539:1991. As the expert technical body, X3J3, should be asked to act as project-editor for this; with a request that it work under X3 I-Project procedures. We should aim to publish the corrigendum within eighteen months, and perhaps update every two years thereafter; assuming this is necessary. 9. Two major functionalities were removed from Fortran 90 as part of the compromises that were made in order to enable work on Fortran 90 to be completed. These were the removal of parameterised derived types, and the facilities for exception handling. Both of these facilities are highly desirable and will probably be early additions to Fortran 90 processors because of user pressure. It would be prudent, therefore, for the details of such extensions to be standardised and published as addenda so as to ensure uniformity of implementation. We should, therefore, initiate two addenda work items: i) to define an upwards compatible extension to allow parameterised derived types in Fortran 90, and ii) to define an upwards compatible extension to allow the handling of exceptions in Fortran 90. 10. We need to look at some more effective method of allowing the language to evolve by facility subtraction as well as by addition. The features marked as obsolescent in Fortran 90 should in fact be removed in the revision envisaged for 1996, but it should be possible for a processor to cease supporting them earlier than that and to still claim some form of formal Fortran conformance; we could perhaps define a Fortran 90 (minus) level of conformance. We could also publish a Technical Report indicating those features of Fortran 90 which are both redundant and undesirable, and hence are candidates for the obsolescent list next revision; removal from Fortran 2000 (minus), say. 11. We should also look at publishing a Technical Report on Guidelines for the production of Fortran 90 bindings. 12. A subgroup should be set up to: i) review the implication of the CLIA standard and the possible need for an addendum to specify in Fortran terms what conformance to both standards would mean. ii) review the proposed drafts of CLID and CLIP as they might impact on Fortran, with a view to both providing input to WG11 and to determining the likelihood of the need for future conformance addenda.