ISO/IEC JTC1/SC22/WG5-N665 THE FUTURE EVOLUTION OF FORTRAN A discussion paper by Brian Meek (UK) Version 2 (corrected), March 1991 This paper, which is a somewhat revised version of the original produced in December 1990, is an expression of personal views only. It does not express a "UK position" or that of any interest group, though of course I hope others will agree with it. The paper mainly addresses immediate and medium term needs, with very little on the long term apart from some remarks in section 5. The details below, especially the timings, may change, depending on progress on completion of Fortran 90 at the March WG5 meeting, but the principles will not. 1. What WG5 should NOT do -------------------------- 1.1 New revision | WG5 should not immediately embark on a full revision cycle. A letter | ballot to initiate such a revision should not be held before 1993; | indeed, any decision on when to hold a letter ballot should not be taken | before 1993. Time needs to be given for Fortran 90 processors to appear; products using Fortran 90 to be developed; experience in implementing and using Fortran 90 to spread; and the upsets over the gestation of Fortran 90 to die down. Embarking at once on a new revision would allow old issues to be perpetuated and even invite the argument "They're revising it already, that admits they got it wrong". 1.2 New functionality | No new functionality should be contemplated before a new revision cycle | is initiated, apart from that allowed for in 3.3 below. The programme below is sufficient to justify a revision to incorporate them into Fortran 2000, without the need for further proposals. People will no doubt come up with new proposals, nothing could stop that, but there is no need for WG5 to seek them, encourage them, or do more than circulate them for information. It is open to anyone who feels strongly enough, and can muster sufficient support, to submit a formal NWI Proposal (NP) for an incremental standard or other addendum, but development of such NPs outside the programme below should be avoided by WG5 itself. WG5 experts and MBs should be asked to exercise self-discipline in this respect during the interval before the initiation of the revision cycle. Naturally, anyone can submit a paper and ask for agenda time for it, and to save the convenor embarrassment I suggest instituting the concept of "agenda votes". That is, when such a proposal comes in, the convenor holds a vote of WG5, without prior debate if in a meeting, to decide whether it should be considered. This would serve to get a proposal on the record and to ensure that the paper would be looked at, but would save discussion time were there no widespread support for it. 2. What WG5 SHOULD do ---------------------- 2.1 Addenda/Related standards | WG5 should for its technical work concentrate for the time being on a | limited number of relatively small projects leading in general to | addenda and/or related standards based on Fortran 90. The suggested | number is six, outlined in section 3 below, and it should not exceed ten. This focuses attention on a small number of limited, achievable objectives, and avoids dissipation of effort over the whole range of issues. 2.2 Strategic issues | WG5 should also devote some attention to long term strategic issues (such | as language architecture) and in particular initiate two studies, | described in section 4 below; see also section 5. The aim here is to ensure that, when a full revision is initiated, WG5 has a clear set of agreed objectives to which it will work. 3. Proposed projects --------------------- 3.1 Corrections addendum | Contingency plans should be made for a corrections addendum to Fortran | 90, and a language maintenance subgroup should prepare the framework for | this. Experience of previous standards of the complexity of Fortran 90 suggests that such an addendum might well be needed. 3.2 Conformity to LCAS | A secondary standard (in the sense of TR 10176) or addendum should be | produced requiring conforming Fortran 90 processors to conform also to | the Language Compatible Arithmetic Standard (LCAS), and perhaps to the | LCAS addenda if these progress quickly enough. Fortran's traditional role will be greatly enhanced by the improved predictability of numerical results that conformity to LCAS will provide. 3.3 Functional modules | A small number of areas should be identified where functionality can be | added to the language by means of standard modules, and incremental | standards (in the sense of TR 10176) or addenda for each of these should | be produced. The module facility provides a mechanism for extending functionality in a disciplined way and this should be exploited. The varying character string module project is already in existence; it is suggested that there could be one or at most two more, possibly based on existing libraries. However, many more would greatly increase the dangers of mutual overlap and interference. There could be more provided they are demonstrably completely disjoint. 3.4 Functional bindings | Supplementary standards, in the sense of TR 10176, binding existing | functional standards to Fortran 90, should be developed, in collaboration | with other groups as appropriate, especially in graphics. The GKS bindings, for example, are to Fortran 77. The much cleaner bindings that can be made with Fortran 90 will benefit the Fortran community. 3.5 Event handling | A project should be started to produce a language-independent functional | standard based upon earlier Fortran work on event handling, and a | supplementary standard produced defining its Fortran 90 binding. The event handling work is too valuable to waste and its provision will meet an identified need. In the way proposed, as a functional standard with a Fortran binding, it would become potentially available to a wider community. 3.6 Error and exception detection and handling | A secondary standard (in the sense of TR 10176) or addendum should be | produced requiring conforming Fortran 90 processors to provide a | specified minimum level of error and exception detection and handling, | following the guidelines in TR 10176. Such a secondary standard would bring "added value", in terms of quality, to the concept of conformance. 4. Proposed studies -------------------- 4.1 Cross-language issues | WG5 should set up a study subgroup to evaluate the potential impact on | future Fortran standardisation of cross-language standards developments | - including but not confined to those in WG11 - and to report, with | recommendations, within one or at most two years. Cross-language projects, like Common Language Independent Datatypes (CLID), Common Language Independent Procedure Calling (CLIP), Remote Procedure Calling (RPC), Bindings Guidelines etc are of long term interest to the Fortran community because a likely important future role of Fortran processors is acting as "servers", especially of Fortran's traditional number-crunching facilities, in distributed or other multi-processor systems catering for a wide variety of needs. Other activities apart from RPC going on outside SC22 that should be looked at include PCTE (Portable Common Tools Environment) and IRDS (Information Resource Dictionary System). 4.2 Formal definition methods | WG5 should set up a study subgroup to evaluate potential formal | definition languages and methods with might be used to define both the | syntax and semantics of future Fortran standards, and to report, with | recommendations, within two years. Just as programming languages like Fortran, rather than natural languages, are needed to specify computations with sufficient rigour, so formal definition languages rather than natural languages are needed to specify the syntax and semantics of a programming language. Fortran has suffered from the lack of formal definition in the past, the most recent instance being the difficulty in reaching agreements on edits to clarify the intended meaning of the natural-language definitions in the text of Fortran 90. The aim of the proposed study is to identify ways of rectifying this. The proposed timescale allows for the outcome of the study to be available before a letter ballot on a new revision is initiated. 5. Longer term considerations ------------------------------ This paper is mainly concerned with the two or three years following completion of Fortran 90, but some thought should be given to longer-term structural issues, in addition to the two proposed studies. Since these could affect many parts of the language it is not suggested that a specific study should be initiated at this stage. The basis on which I suggest thought be given is the consideration that there is a great deal of functional commonality between languages, and that this is likely to continue. There is no sense in different language groups duplicating effort in adding, say, parallel processing, or object-oriented features, or support for a multiplicity of natural languages; it makes much more sense to follow the graphics model and develop language-independent standards for them with bindings to individual languages. However, the same is also true of core features of languages, input-output being the outstanding example. It makes no sense at all for each language to solve separately the problems of straightforward text I/O, yet they do so. With its module capability, Fortran 90 would be a good place, first to recast I/O in module form, and then to define in a separate document the SEMANTICS of I/O in a language-independent manner. There are of course other languages which can be learned from in this respect; and I also suggest that Carl Burch's X3T2 paper on language-independent I/O be circulated to WG5 for information and consideration. I have given I/O as the obvious example, but there are other areas which might well merit the same kind of treatment. 6. Concluding remarks ---------------------- I believe the programme outlined in sections 3 and 4 is quite enough to keep WG5 busy over the next two years, in ways that will deliver identifiable payoffs in a timescale much shorter than the 10-15 years which experience indicates is likely to be the case if a full revision is embarked upon now. There are good reasons for delaying the start of a new revision cycle anyway; this paper has sought to demonstrate that this time can be used productively.