ISO/IEC JTC1/SC22/WG5 - N52 To: ISO Meeting of Fortran Experts, June 1982 From: David Muxworthy, U.K. Subject: Comments on X3J3 Proposals Preamble -------- These comments are an attempt to summarize discussions at BSI and BCS meetings on Fortran since the last ISO Fortran Experts meeting. Any criticisms of X3J3 proposals are intended to be constructive. Members of the Fortran community in the U.K. are very much aware of the prodigious work of the members of the X3J3 committee in bringing the proposals to their present state and are especially grateful for their openness and willingness to discuss their work with those outside X3J3 both in the U.S. and abroad. It is gratifying to note that a number of the suggestions made by other countries at the ISO Fortran Experts meeting in 1980 have now been incorporated into the X3J3 proposals. Although for some minor uses Fortran has been supplanted, rightly, by other languages, we believe that Fortran, whose imminent demise was announced within IBM in 1961 and which has subsequently survived the advent of Algol 60, PL/I, Algol 68 and Pascal, will continue to be the only practicable scientific language for widely portable and for large-scale programs for the foreseeable future. It is therefore very important that it evolves in a way which loses none of its current advantages and which is acceptable to the majority of its current users. Milestones ---------- A persistent criticism of X3J3 at the 1978 and 1980 Fortran Experts meetings was that the committee were moving too far, too fast and this criticism has been echoed to some extent at domestic U.K. meetings. This is not to say that the current X3J3 development work should not be proceeding but it is important for the credibility of Fortran 8X that it build on experience with Fortran 77 and that it resolve all the problems posed by it for both implementors and Fortran users. Fortran IV came into general use in 1962-64 and the revision of its standard took place in 1970-76. Thus the revision built on 6-12 years‘ experience of use. Fortran 77 is still not available to a substantial minority of potential users, as the London Fortran Forum showed, so that it can not be until 1984 at the earliest that there can be even as wide an experience of it as there was of Fortran IV in the mid-1960's. Indeed, so far as the writers of large-scale portable programs are concerned it is so far largely untried because of the gaps in its coverage across machines. We are aware of the pressures from various sectional interests to complete Fortran 8X, particularly to define array-processing as quickly as possible, and to produce a language to be able to compete with Ada. However it is by no means clear that Ada poses a threat to Fortran and we submit that it is more important that Fortran 8X is right than that it is available soon. General Strategy ---------------- The U.K. has pursued the general themes of more regularity and less permissiveness in the language for more than a decade. In the development of Fortran 77 there was some antipathy within X3J3 to type COMPLEX and the functionality for type REAL was not uniformly provided for type COMPLEX, thus leading to unpredictable irregularities. It is pleasing that these have been removed and that COMPLEX is a fully fledged type in Fortran 8X. (At an IFIP TC2 conference in 1981 it was made clear that for some classes of user the main advantage of Fortran was the provision of type COMPLEX). We continue to commend the attributes of regularity and less permissiveness. In 1980 the U.K. reported criticisms that X3J3 was overly concerned with large machines and did not make sufficient allowance for mini-computers. We urge the committee when defining the core and its modules to ensure that the core will be implementable on smaller machines and not to abandon micro-computers to other languages such as Basic and Pascal. We also urge the committee to bear in mind the problem that old object code may exist for which no source is available and to define the language transition module if possible in such a way that old object need not necessarily be made obsolete. Remarks on X3J3 Proposals ------------------------- In general terms the BSI/BCS meetings approved of the X3J3 proposals, subject to the provisos above. Some remarks follow. They are grouped by section number in X3J3 document S6.81. 1. Control Structures ------------------ The structures described in this section were the most obvious omission from Fortran 77. Although the functionality of the WHILE loop is provided by an indefinite DO and an EXIT there is some sentiment in favour of an explicit WHILE loop. There has been no pressure for an UNTIL loop. There is a distinct need for a multi-level EXIT from within a nest of loops; it is assumed that the naming option of section 1.5 is a precursor for such a facility. The CASE construct illustrates perfectly the dichotomy between the pragmatic and the conformist attitudes to a permissive standard. The CASE proposal states that the case expression must match one and only one block selector. What happens if it matches no block selector? The pragmatic view is that, analogous to a computed GOTO, the select block is not executed, no error is reported and execution continues. The conformist view is that a situation not catered for in the program logic has arisen, that this must be reported and possibly execution terminated. The literalist view is that this is a non-standard conforming program and therefore the matter is not the concern of the standard. But the ultimate purpose of a standard is to ensure uniform performance across different processors. The U.K. position is that the standard should explicitly state what should happen if the condition is not complied with. There is already a precedent in Fortran 77 (section 12.6) which states that in certain error circumstances execution of the program should terminate. It may not be that such a drastic action is needed here but what is required is that the action be defined. In this particular example it is noteworthy that the ISO Pascal standard committee rejected the concept of a CASE DEFAULT because it was logically unnecessary (IF-CASE-ELSE-DEFAULT) and because such a catch-all could reduce the error-checking ability of a program. CASE DEFAULT could thus be seen as a typically pragmatic Fortran compromise so, given that it is provided, programmers should be made to use it explicitly if they wish to use its facility. On the trivial matter of syntax, it has been pointed out that ENDDO would be more consistent with ENDIF, ENDSELECT, ENDSUBROUTINE etc although REPEAT is better English. The removal of the real DO index is approved. 2. Data Structures --------------- We welcome the fixed data structures already approved and trust that varying data structures will be incorporated in the final proposals. 3. Array Processing ---------------- There is concern that the bulk of array processing facilities should not be in the core lest this inhibit implementation of the core on smaller processors. It is good that the proposals themselves allow programs to be written which follow the logic of mathematics closely and yet do not imply any particular methods of linear algebraic computation which could have tended to mislead naive users. 4. Procedures and Functions ------------------------ The ability to omit arguments to subprograms and to specify arguments by keywords is welcomed. Our only comments are that section 4 of X6.81 is overly brief (for example may OPTIONAL and INTENT statements appear in an interface description as well as in a called subprogram ?) and that since interface-descriptions give increased possibilities of inconsistency between program units, some definition of the actions to be taken in such circumstances would be desirable. 5. Program Form ------------ We would draw the attention of the committee to the problem of different maximum source line lengths; in the case of Pascal there are at least five different source line lengths in common use (72, 80, 96, 110, 128) and it is trivial but time-wasting and potentially destructive of source layout to have to convert between them. This is a problem which standard Fortran has successfully avoided up to now. It might be appropriate to specify a maximum permitted line length as well as the minimum of 72. We commend the fact that all characters of a name are significant. This is particularly important in Fortran where a typing mistake can generate a new variable because of explicit declaration being unnecessary. We again question whether all operating systems will be able to cope with external names as long as 31 characters without creating special Fortran environments and whether there could be problems with the use of underline as an alpha-betic character. At least one operating system treats underline as a separator and another treats it as a null character used only to aid legibility. In the 1978 BSI national survey, the introduction of significant blanks was the most strongly disliked single proposal for Fortran 82, as it then was. Since X3J3 do not appear to be making much use of this facility, such as deleting all other separators, this criticism can probably be ignored However it would appear from X6.81 that it is not possible to insert blanks into numeric constants to improve legibility. We wish to retain this facility from Fortran 77. Now that the less than and greater than signs have been included in the language we suggest that they be used in their mathematical sense. 6. Precision Data Type ------------------- Several British numerical analysts have contributed to the precision proposals adopted by X3J3 and we are naturally in favour of them. In particular we favour the expansion of type COMPLEX to be fully parallel with type REAL and the resolution of the potential combinatorial problem at argument association. At recent U.K. meetings reservations about efficiency in two areas have been expressed. The first is to do with the action of a processor if there is no native data type which meets the specified range and requirements. Should it be able to provide extended facilities by software? Should it do so when the user may have preferred to compromise slightly and to have used a native data type? There seems to be a particular danger of naive users asking for an exponent range of 99 when a lower value would have been acceptable. This is so fundamental to a program that the standard should specify the action, even at the expense of extending the syntax to give the user further options. The second area is that, there is still concern about the problems of efficiency when compiling subroutine libraries containing generic type statements. 7. Dynamic Storage and Recursive Procedures ---------------------------------------- These facilities are welcomed. In particular automatic arrays should help to mollify those package authors whose storage management schemes in Fortran 56 are inoperable in Fortran 77 because of restrictions on the storage of characters. 8. Bit Data Type ------------- This is very important for certain types of application. There has been inconclusive debate over whether it should be in the core language. 9. Internal Procedures and Interprocedure Data Sharing --------------------------------------------------- This has been a particular interest of Dr J.K. Reid over the past two years. and is the subject of a presentation by him at this meeting. 10. Input-Output ------------ One of the main strengths of Fortran vis-a-vis other scientific languages is the input-output and it is notable that the proposals for this area are in the nature of clarifications and relatively minor extensions. It is also pleasing to see that several points mentioned in the U.K. submission to the 1980 Fortran Experts meeting have been dealt with in section 10 of X6.81. The remaining contentious area in input-output is in deciding what exactly constitutes an error and, after an error condition is raised when if at all it is rescinded. It is understandable that decisions on this are awaiting development of event-handling proposals. 11. Compile-Time Facilities ----------------------- It is unfortunate that macro facilities appear continually to fail to be discussed fully by X3J3. Apart from their intrinsic value, for which there is a definite body of opinion in favour, the adoption of comprehensive macro facilities would allow other language features to be expressed in terms of macros. This would mean in turn that many of the sectional interests urging X3J3 to adopt particular features could be diverted towards using macros. Hence it is in X3J3's own interests to adopt macros quickly. 12. Character Data Type Extensions ------------------------------ Academic computer scientists have poked fun at Fortran for many years and it is feared that having two such closely parallel but different facilities as STRING and CHARACTER will give renewed cause for mirth. More importantly, it will cause confusion to users of the language, and judging by Fortran 77, possibly also to implementors. Since STRING is more powerful and more general it alone should be in the core and CHARACTER should be relegated to the compatibility module. 13. Language Architecture --------------------- Opinions about the core and modules architecture are reserved. In theory it is an excellent idea providing a sound growth path for the future. In practice there are serious doubts about whether it can be made to work. Each legitimate combination of core and modules will have to be considered as a language in its own right, free of ambiguities. Basic concepts such as precision, storage association and argument association are different in Fortran 77 and in the core proposals. If they are used in full native mode in the two contexts it is not possible to envisage a single standard- conforming program consisting of core program units and core plus transition module program units. There are horrendous possibilities of implementor-defined extensions allowing all these concepts to be mixed in a single program unit. However if not all full facilities are used, for example only default precisions are used, no assumptions are made about storage -ewes association and only Fortran 77 compatible argument association is used then such a mixed program could exist successfully. It is our impression that this has not been fully explored by X3J3; it is hoped that the concept can be made to work. 14. Implicit and Data Statement Extensions -------------------------------------- We repeat our 1980 request for regularity to allow a zero length implied-DO loop in a DATA statement, e.g. in PARAMETER (N= ) DATA (A(I),I=1,N) /N*30/ N should be allowed to be zero, since such a null implied-DO loop is allowed in an input-output list. 15. Unresolved Items ---------------- Of the unresolved items the one which concerns the U.K. most is event-handling. The compatibility module (Fortran Experts Meeting 1980 minutes pp 77-92, X3J3 paper 77(*) DTM-1) cannot usefully be further defined until it is known what checks on a program at run-time it is reasonable to expect a processor to make. There is little information to be gleaned from the current standard on this but the form of event-handling approved by X3J3 must give much closer guidance. Of other items not mentioned above aliasing is of especial interest and several detailed points: particularly to do with problems with Fortran 77, remain from our 1980 submission (minutes pp 5-10) and are not repeated here. Change of X3J3 Secretary ------------------------ We should like to record our deep appreciation of Loren Meissner's work as X3J3 secretary. He has provided overseas groups with an exemplary supply of documents, has acted as secretary to ISO Fortran Experts meetings since their inception, has produced the admirable "For-Word", has given numerous presentations on Fortran and has still found time to be a very active member of X3J3 itself. We offer our best wishes to him and to his successor.