From dtm@castle.ed.ac.uk Mon Oct 4 10:19:43 1993 Received: from sun2.nsfnet-relay.ac.uk by dkuug.dk with SMTP id AA20279 (5.65c8/IDA-1.4.4j for ); Mon, 4 Oct 1993 09:23:15 +0100 Via: uk.ac.edinburgh.castle; Mon, 4 Oct 1993 09:23:09 +0100 Date: 04 Oct 93 09:22:47 BST From: D Muxworthy Subject: Language Evolution Proposals To: David_Mattoon_at_CTC@relay.proteon.com Cc: sc22wg5@dkuug.dk Message-Id: <9310040922.aa27195@uk.ac.ed.castle> X-Charset: ASCII X-Char-Esc: 29 David, Could you please add to the pre-meeting distribution? Thanks, David --------------------------------cut------------------------------------------ X3J3/93- To: X3J3 From: BSI Fortran Panel Subject: Language Evolution Proposals Date: October 4, 1993 1. Introduction The BSI Fortran Panel was pleased to be given the opportunity to make detailed proposals for the next revision of the Fortran standard. This paper is the first iteration of proposals for language evolution. It discusses the principles of changes to the language; detailed text changes to the standards document will be formulated later. The panel has made some effort to gather opinion from the user population on language evolution, both by surveying Fortran users and programs at members' own institutions and by general e-mail trawls. The panel would of course welcome input from X3J3 and other sources and would develop proposals accordingly. 2. Rationale The purpose of the standard is (F90 section 1.1) "to promote portability, reliability, maintainability, and efficient execution of Fortran programs for use on a variety of computing systems". Because of the way in which Fortran has developed historically and particularly because of the large number of extensions made in going from Fortran 77 to Fortran 90, the current language has a number of redundant statements or facilities. That is, a computational process or sequence of operations may be expressed using quite different Fortran statements. This means that language processors must provide for statements which may be rarely if ever used and which are redundant in the sense that a standard Fortran program to achieve the identical computation could be written using alternative statements. This requirement to carry unnecessary and unproductive overheads applies also to manuals and possibly to text-books and other training materials and to the minds of old and new Fortran users. Those developing Fortran 90 recognized the need for language evolution and defined the concepts of deleted and obsolescent features (F90 section 1.6) but, because of the intention that a feature be deleted only after a revision in which it is marked as obsolescent (F90, page 5, lines 37-38), the set of deleted features in Fortran 90 is empty. The relatively more conservative committee which developed Fortran 77 had taken a much more radical line on language evolution by deleting the Hollerith data type and supplanting it with type CHARACTER. That is, when a clearly more user- friendly and portable facility had been added to the language, the committee did not shrink from deleting a facility which was used in probably more than three-quarters of existing Fortran programs around the world. The deleted feature was retained in an appendix in the standard for vendors to provide while their customer base wanted it. There was negligible chance that the deleted feature would be used in any newly written programs. It is important to note that there was no negative reaction from the user community. Fortran 90 was remarkable in that modern programming facilities were added to an old language, thus allowing for both compatibility and continuity on the one hand and growth and modernity on the other, but if Fortran is not to atrophy under the weight of historical dross it must shed some of the twenty- or thirty-year-old features which are little used in current programs and which would never be used in new ones. It is proposed that the basic principle for considering deletion should be that all nine of the potential candidates (F90 section 1.6 and B.2) should be deleted from the language at the next revision, unless an outstandingly strong case can be made for retention; we are not aware of any such case. The deleted features may be retained in the standard in non-normative appendices in the style of Hollerith data in the Fortran 77 standard. As numerous commentators have pointed out, even after removal of the current obsolescent items, there is still much unnecessary duplication in Fortran. A new set of obsolescent features should be defined to allow for further development in the years 2000-01. An initial list of candidates for obsolescence is given below. X3J3 may well wish to suggest additional items. 3. Discussion of candidates for deletion 3.1 Arithmetic IF There is a sentimental attachment to this statement, which goes back to the first Fortran language of 1954. Nevertheless its use diminished considerably after the advent of the logical IF in the early 1960s and its use in its most primitive form (with three different labels, none of them relating to the statement following the IF) makes a program virtually unreadable. Since its use in new programs is unthinkable and it is trivially replaceable by logical IF and GO TO statements, it should now be deleted from the language. 3.2 Real & double precision DO variables This was a feature copied from Algol 60 to Fortran 77 at a time when there was a move to relax the strict type rules of Fortran 66. Subsequently it was realized by IFIP that it was a mistake in Algol and the feature did not appear in Algol 68. The problem is that because of the nature of real arithmetic it is not possible, without detailed knowledge of the arithmetic and implementation of a system, to predict the behaviour of a program using this feature. Thus use contradicts the first purpose of the standard, the promotion of portability of programs. Since this deficiency has been known for over twenty years, the feature has been relatively little used in Fortran and programs are readily convertible to use an integer control variable. Fortran should recognize that a mistake was made and the feature should now be deleted from the language. 3.3 Shared DO termination and termination on a statement other than END DO or CONTINUE Clear separation of DO loops was one of the features promoted in IBM's Improved Programming Techniques of 1972-73 and it was generally accepted as good practice by the mid-1970s. The problem with shared DO termination is possible confusion when the terminating statement is labelled and is the object of a GO TO statement. Most new programs use separate termination but probably a majority of programs use shared termination to some extent. Nevertheless, it is suggested that Fortran should fall into line with all other major languages and remove this feature, while accepting that vendors will probably continue to provide for it until usage dies out. 3.4 Branching to an END IF from outside its block It was surely an oversight in Fortran 77 to allow this feature and no-one would deliberately write a program to do this. It should now be deleted. 3.5 Alternate RETURN The alternate return was introduced into Fortran in the early 1960s to mimic the style of interface to subroutines then available in assembly programming. Although quite useful, it requires the use of one or more labels and section B.2.1 of Fortran 90 clearly demonstrates that the use of a return code and case construct can give the same effect in a more controlled, more contained and more readable fashion. The alternate return should now be deleted from the language. 3.6 PAUSE statement The PAUSE statement is a relic from the time when it was the only means of communicating with the operator of a system. The definition of the PAUSE statement in the standard is so weak that it is impossible to write it in a program intended to be portable and expect with any confidence that it will be implemented as intended. If the intent is to output a message, receive a response and then branch according to the response, this is more surely and more portably achieved by using other statements, such as WRITE and READ. This statement was conceived in terms of the operating systems of the mid-1950s; there is no need for its perpetuation into the 21st century. 3.7 ASSIGN and assigned GO TO These statements mimic styles of branching useful in assembly programming and were often used in Fortran for returning from open-coded procedures. They were however a very frequent cause of confusion and error for novice programmers, and a potential source of obscure error in all Fortran programs. General discouragement has limited their use in the past twenty years and since they can easily be supplanted by other statements, they should now be removed from the language. 3.8 Assigned FORMAT specifiers This was an ad hoc, irregular addition to Fortran 77 (thought up by J.C.Noll while shaving one morning). Because of the way formats are often implemented, it gives an efficient way of dynamically associating an input/output list with different formats. However, as mentioned in B.2.4 of Fortran 90, it can also be an obscure source of error and is not intuitive for novice programmers. It should be consigned along with ASSIGN and assigned GO TO. 3.9 cH edit descriptor This feature was a logical associate of Hollerith data. Presumably it was not deleted along with the rest of Hollerith data because it can occasionally be useful to have all counts present in a format for a table heading, say. Nevertheless it had been effectively superseded by vendor extensions to Fortran 66 by the early 1970s and it is very rarely used in new programs. It is, or was, a common cause of error when the count was incorrect. It should be deleted. 3.10 Summary The cases above do not all have the same force. It is suggested that the priorities for X3J3 should be as follows. Priority 1 (no case whatever for being admitted to Fortran 95) Real and double precision DO variables Branching to END IF Alternate RETURN PAUSE assigned GO TO cH edit descriptor Priority 2 (should be admitted to Fortran 95 only if a very strong case can be made) Arithmetic IF Shared DO termination ASSIGN, assigned formats 4. Discussion of new obsolescent features 4.1 Computed GO TO The computed GO TO of the 1950s evolved into the CASE construct of the 1960s (in other languages, of the 1980s in Fortran). CASE is a generalized and easier to use and understand version of the computed GO TO and completely supersedes it. It is unlikely that the computed GO TO will be used in new Fortran programs. To flag it as obsolescent now will allow it to be deleted in due course. 4.2 ENTRY The ENTRY statement appeared in Fortran at a time when procedure calling overheads were a possibly significant drain on run-time efficiency and before it was generally realized that the sudden change of environment of the execution path was a potentially rich source of programming error. Worse, the statement is often used in a non-standard manner to establish argument associations for a procedure which it is assumed will be retained at a subsequent entry. If a GO TO can be considered harmful, an ENTRY can be positively pestilential in the hands of other than an expert programmer. Since relative computing priorities have changed since the mid-1960s, the statement should be marked obsolescent. The statement has proved useful to control access to a collection of data. The collection can be held in scalar and array variables that are local to a procedure and is accessed only through calls to the procedure and its entry points. However in Fortran 90 this feature is better provided through private data in a module. 4.3 Statement functions Statement functions were a neat idea in the original Fortran. However they appear to be little understood and little used and are a potential source of error since the syntax is so easily confused with an assignment statement and the restrictions on the form of the expression are not intuitive. Who has not written a program where an intended array element reference was mistakenly identified by the compiler as an incorrect statement function definition? One common use appears to have been in library procedures to plug a deficiency in use of generic external references, a matter dealt with explicitly in Fortran 90. Internal procedures were added to Fortran 90 in part to supersede statement functions so, since they are now redundant, they should be deemed obsolescent in Fortran 95. 4.4 DATA statements amongst executables The statement ordering rules of Fortran 66 (F66 section 9.1.1) allowed DATA statements to appear anywhere in a program unit after the specification statements, following the practice of major vendors' language definitions. This rule was perpetuated in Fortran 77 and hence in Fortran 90 for compatibility. However in the new forms of declaration statement in Fortran 90, data initialization is integrated with the corresponding variable declaration and even in Fortran 77 it was extremely rare to find a program with a DATA statement not placed before the executable statements. Moreover, grouping DATA statements together reduces the chance of their inadvertently contradicting each other. Since the ability to scatter DATA statements in this manner is not needed and is a potential source of error, it should be marked obsolescent to allow its eventual removal. 4.5 Assumed character length functions Assumed character length for functions is completely at variance with the philosophy of Fortran 90 that the attributes of a function result depend only on the actual arguments of the invocation and on any data accessible by the function through host or use association. This facility may be replaced by the use of a subroutine whose arguments correspond to the function result and the function arguments. 4.6 Fixed form source Punched cards were very useful, indeed absolutely indispensable, in their day but are museum pieces now; card readers are almost impossible to find. New and amended programs are now entered via keyboards where it is a nonsensical overhead to have to locate positions 6, 7 or 72 on a line. No-one keying in a new program unit in Fortran 90 will choose the fixed source form once they have learned the free form. Thus the fixed form truly is obsolescent in the normal English sense of the word and should be marked as such. It is a simple matter for a tool to convert from fixed to free form. 4.7 Assumed-size arrays Assumed-size arrays were formally introduced into Fortran 77 after long de facto use with the right-most dimension written as '1' rather than '*'. They were useful in the context of Fortran 77 both because they were not required to have the same rank as the associated actual argument and because the total size of the dummy array did not have to be specified; they could thus be used, amongst other things, for passing array space to be allocated dynamically by the programmer. The advent in Fortran 90 of automatic arrays, assumed-shape arrays and deferred-shape arrays gives new functionality, allows the programmer to specify such requirements more directly and takes away any reason to use assumed-size arrays. They should therefore be marked obsolescent and allowed to die away in due course. 4.8 Pointers in storage associated contexts Pointers were designed to be used mainly with dynamically allocatable space and they have limited utility in pointing at fixed storage. Because of the presumed implementation method and the consequently severe restrictions placed on them, they are error-prone when themselves placed in common blocks. Such pointers must become storage associated only with pointers of the same type, type parameters and rank. (A pointer is not allowed to become storage associated with another pointer via an EQUIVALENCE statement). The potential advantage of having a pointer in a common block is far outweighed by the potential disadvantages. The feature should be marked as obsolescent to indicate this. 4.9 The operators .EQ., .LE., etc. The operators .EQ., .LE., etc. are now redundant in the language since ==, <, etc. are exact equivalents. Not only are they equivalent, but the new forms are much more readable. The older forms should be marked obsolescent. 5. Proposals 5.1 The following Fortran 90 features shall be deleted from the revised language: Arithmetic IF Real and double precision DO variables Shared DO termination Branching to END IF Alternate RETURN PAUSE ASSIGN, assigned GO TO, assigned formats cH edit descriptor 5.2 The following Fortran 90 features shall be deemed obsolescent in the revised language: Computed GO TO ENTRY Statement functions DATA statements amongst executables Assumed length character functions Fixed form source Assumed size arrays Pointers in storage associated contexts .EQ., .LE. etc operators 6. Further candidates for obsolescence 6.1 WG5 Requirements Repository For completeness, the following candidates for obsolescence are in the current WG5 requirements repository (WG5-N904): - EQUIVALENCE - use of COMMON to achieve EQUIVALENCE We do not propose these items as we consider that they would not be acceptable to the user community at this time. 6.2 Other items During discussions on the preparation of this paper, several other items for consideration for obsolescence have been suggested by members of the BSI panel and many others have been submitted by other Fortran users. While all of them have some merit they have not been proposed at this stage as it was thought that they would not be generally acceptable. It is not useful to list them since in combination they cover a large proportion of the features in the language. This is not to say that we consider the above list to be exhaustive and, as stated in the introduction, we should be pleased to develop further proposals. David Muxworthy (editor), for BSI Fortran Panel ---------------------------------end------------------------------------------