From dtm@castle.ed.ac.uk Sun Dec 29 18:33:47 1993 Received: from sun2.nsfnet-relay.ac.uk by dkuug.dk with SMTP id AA22775 (5.65c8/IDA-1.4.4j for ); Wed, 29 Dec 1993 19:33:01 +0100 Via: uk.ac.edinburgh.castle; Wed, 29 Dec 1993 18:34:00 +0000 Date: 29 Dec 93 18:33:47 GMT From: D Muxworthy Subject: Revised Language Evolution Proposals To: David_Mattoon_at_CTC@relay.aar.com Cc: sc22wg5@dkuug.dk Message-Id: <9312291833.aa01201@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/94- To: X3J3 From: BSI Fortran Panel Subject: Revised Language Evolution Proposals Date: December 29, 1993 1. Introduction This is a revised proposal on language evolution following the discussion and straw votes at the X3J3 meeting in November 1993. The basic principles of language evolution are assumed to be those defined in Fortran 90. 2. Rationale for Language Evolution The purpose of the Fortran standard, as of the earlier 1966 and 1977 standards, is (F90 section 1.1) "to promote portability, reliability, maintainability, and efficient execution of Fortran programs for use on a variety of computing systems". National standards organizations were set up initially "to eliminate the national waste of time and material involved in the production of an unnecessary variety of patterns and sizes of articles for one and the same purpose". When the Fortran 77 standard was being developed, the then committee felt able to delete from the 1966 standard a feature which had been superseded by a vastly more portable and user-friendly facility in the new standard, even though that feature was very widely used. Subsequently more formal rules on deletion from a programming language standard were introduced by ANSI, leading to the concepts of obsolescent and deleted features being defined as part of Fortran 90 and used also in other leading programming languages including relatively modern ones like Ada. The intent, obviously, was to allow the eventual deletion of features as a language developed, so as to avoid it becoming larger and larger and to avoid keeping alive features which were no longer needed. The definition of deleted and obsolescent features is given in F90 section 1.6. This is: "1.6 Deleted and Obsolescent features This international standard protects the users' investment in existing software by including all of the language elements of Fortran 77 that are not processor dependent. This document identifies two categories of outmoded features. There are none in the first category, deleted features, which consists of features considered to have been redundant in Fortran 77 and largely unused. Those in the second category, obsolescent features, are considered to have been redundant in Fortran 77, but are still used frequently. 1.6.1 Nature of deleted features (1) Better methods existed in Fortran 77. (2) These features are not included in this revision of Fortran. 1.6.2 Nature of obsolescent features (1) Better methods existed in Fortran 77. (2) It is recommended that programmers use these better methods in new programs and convert existing code to these methods. (3) These features are identified in the text of this document by a distinguishing type font. (4) If the use of these features has become insignificant in Fortran programs, it is recommended that future Fortran standards committees consider deleting them from the next revision. (5) It is recommended that the next Fortran standards committee consider for deletion only those language features that appear in the list of obsolescent features. (6) It is recommended that processors supporting the Fortran language continue to support these features as long as they continue to be widely used in Fortran programs." Item (6) is meaningless if taken literally since obsolescent features are fully part of the standard. Presumably it was intended to mean that items which have been deleted from the language should continue be supported by vendors as long as they are needed by their customers. This is what happened with Hollerith data type, deleted from Fortran at the 1977 standard. These criteria assume the continued demand for and popularity of Fortran. Another criterion which should be taken into consideration is that to attract use by the younger generation, Fortran must seek as far as possible to lose its dinosaur image. It appears to be not uncommon for science and engineering undergraduates to be taught Fortran amidst a welter of snide remarks from computer science demonstrators. A related but distinct criterion is one specified in item 15 of the WG5 requirements for Fortran 95, that efforts should be made to reduce irregularities in Fortran. 3. Deleting features from Fortran 90. 3.1 Candidates The items which are potential candidates to be deleted from Fortran have already been decided; they form the set of obsolescent features in Fortran 90. Moreover, the guidelines for use in deciding on deletion are given in Fortran 90 and are repeated above. The candidates are listed in section B.2 of Fortran 90 and are: - 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 3.2 Criteria The essential criteria are numbers 2, 4 and 6. Number 2 addresses the concept of change in programs. It implies that it is expected that users of Fortran will adopt new standard features, which typically allow an algorithm to be expressed more easily. Moreover, the concept that dusty deck software will be standard-conforming without any change whatever without limit of time is not supported. Number 4 addresses the concept of usage. The extent of usage of individual features is impossible to determine accurately, although it is possible to conduct limited surveys of use (as members of the BSI panel have done amongst users at CERN, Liverpool University and readers of newsgroup comp.lang.fortran) and of the prominence given to various features in Fortran textbooks. It will always be possible to find individual users of a particular feature. The question to be addressed is whether, given hundreds of thousands of Fortran users world-wide, it is reasonable to burden the majority (in compilers, manuals, textbooks, etc) with a minimally used, redundant and easily replaceable feature for the benefit of a minuscule fraction of users. Number 6 addresses the concept of continuity for items deleted from the standard. With the precedent of Hollerith data type, we are wholly in favour of vendors continuing to support such dying features, outside the standard, so long as their customers wish to use them. 3.3 Matching deletion candidates with criteria The following table classifies candidates for deletion against criteria. Broad classes are used since any attempt at finer definition is likely to be unproductive. For most of the criteria (details are given below the table), category 1 is 'low', 2 is 'medium' and 3 is 'high'; for example, portability of arithmetic IF is rated high, portability of real DO index is rated low. For all of the criteria, 1 denotes 'poor' and 3 denotes 'good'. port rel mnt eff reg use mis din auto first arith IF 3 3 2 3 2 3 3 1 easy 66 real DO 1 1 2 3 3 1 1 2 poss 77 shared DO 3 2 2 3 2 3 2 1 poss 66 br END IF 3 3 2 3 1 1 2 1 easy 77 alt ret 3 3 2 3 2 2 2 1 easy 66 PAUSE 1 1 1 2 3 1 2 1 easy 66 ASS GO TO 3 2 1 3 1 1 1 1 poss 66 Ass format 3 3 2 3 1 1 3 1 poss 77 cH edit 3 2 2 3 1 2 1 1 easy 66 where the column headings represent: port portability rel reliability mnt maintainability (ease of interpretation of someone else's code, or one's own six months later) eff efficiency (assumed to be of object code, not of programmer's time) reg regularity use estimated usage in existing programs world-wide mis propensity for misuse (3 low, 1 high) din dinosaur rating (3 low, 1 high) auto amenability to automatic source translation to alternative (easy denotes the possibility of translation by a simple source manipulation tool, maybe a good editor; poss denotes that a more powerful tool is needed; prog denotes that analysis and recoding by a programmer may be necessary) first first standard with this feature 4. New obsolescent features 4.1 Criteria It is assumed that the criteria for marking a feature obsolescent in Fortran 95 will be analogous to those in Fortran 90, with '77' replaced by '90'. The object of marking features 'obsolescent' now is to allow them to be deleted from the year 2000 onwards, not to require that they be so deleted. 4.2 Candidates A list of candidates for obsolescence had been compiled by WG5 before its last meeting and formed the basis for the previous proposal from BSI. Two items on the WG5 list, EQUIVALENCE and the use of COMMON to achieve EQUIVALENCE, were not proposed last time. In view of the discussion at X3J3 and subsequently, it is appropriate to withdraw from the proposals .EQ. etc operators and to add the CHARACTER* form of the CHARACTER declaration. Although the pointers in storage associated contexts proposal was not enthusiastically received by X3J3, it has been retained for reconsideration and to demonstrate its scoring in the spreadsheet. The proposals for obsolescence are thus: - 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 - CHARACTER* declaration 4.3 Matching obsolescence candidates with criteria This leads to the following table, using the same definitions as above. port rel mnt eff reg use mis din auto first comp GO TO 3 3 2 3 2 3 3 1 easy 66 ENTRY 2 2 2 3 1 2 1 1 prog 77 state fn 3 3 2 3 2 2 3 2 easy 66 DATA in exec 2 3 1 3 1 1 1 1 easy 66 ass len ch fn 3 3 2 3 1 2 2 2 poss 77 fixed source 3 3 1* 3 2 3 1* 1 easy 66 ass size arr 3 3 2 3 1 3 2 1 easy 77 ptrs in st cxt 1 1 1 2 1 1 1 2 prog 90 CHARACTER* 3 3 3 3 1 3 3 2 easy 77 * The reason for the code 1 being given to fixed length source is that with modern editors and terminal emulators, which have a wide choice of font sizes and possibly even variable width fonts, it is more difficult than in the past to locate columns 6, 7 and 72 on a line. 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 CHARACTER* form of CHARACTER declaration 6. Additional information The BSI paper on language evolution dated October 4, 1993 was circulated on newsgroup comp.lang.fortran after the X3J3 meeting in November. It generated a large number of replies to the newsgroup, plus a further set by e-mail. A summary of these will be forwarded to X3J3 (and WG5) separately. David Muxworthy, for BSI Fortran Panel ----------------------------------------end----------------------------------