& *H me --

El2 ELSEWIER Computer Standards & Interfaces I8 (1996) 3 1 S-320

lilumfRSUVlOIUlOS Ii IlllERHuai

Fast forwarding Fortran, Part 1: Clean Fortran L.M. Delves a, D. Lloyd a, T. Lahey b

a N.A. Sofiware Ltd, Roscoe House. 62 Roscoe Street, Liverpool LI SOW, UK h Lahey Computer Systems, Incline Village, Neuadu. USA

Abstract

Fortran 90 represents an important advance in language design for scientific and engineering computing, and will we believe be widely used. However, a number of language facilities widely regarded as useful, still are absent from Fortran 90. Others, widely regarded as adding nothing but irregularity to the language, remain part of it, and their continued existence makes the addition of new features more difficult. And yet, the weight of existing code makes deletion of these features from the IS0 standard a difficult and slow process. In this paper we discuss a version of Fortran 90 which we refer to as Clean Fortran. It contains a number of restrictions to the current language. The restrictions are made to remove irregularities. The resulting language is intended to form a base from which much-needed language extensions can be more readily incorporated. We discuss also a way in which Clean Fortran, or some agreed variant of it, can be readily incorporated into the current language evolution cycle by re-introducing a Subset Fortran language.

Keywords: Language development; Clean Fortran; Language irregularities

1. Introduction

Fortran 90 has brought Fortran struggling into the 1970s so far as language facilities are concerned. Luckily for its adherents, that is where other main- stream general-purpose languages (C/C + + , Ada83) sit too. We believe that Fortran 90 represents an important advance, and that its use will spread rapidly. But Fortran cannot afford to sit still: its rivals are still either more advanced or are moving on become so:

0 C + + allows at least a restricted form of object oriented programming

0 Ada9X is now here and does so too.

A number of new Fortran 90 features (for exam- ple, derived types) have restrictions imposed by the

Elsevier Science B.V. P/I SO920-5489(96)01008-2

need to finalise the standard in a finite time. These restrictions do not meet the needs of the program- mer.

Others, such as generics and exception handling, failed to make the standard at all.

Fortran 90 still carries the dead weight of its past in terms of a relatively wide range of obsolete and superseded language features, together with an im- pressive range of language irregularities in part at least enforced by the carrying of these features.

Worse still, architectures are moving on faster than Fortran (but faster than other languages too): shared and distributed memory SIMD and especially MIMD parallelism are now common in scientific and engineering environments, but Fortran 90 provides no access to MIMD programming.

The current Fortran standard [1] of course has a well established upgrade path: IS0 WG5 and ANSI

316 L.M. D&es et al./ Computer Standurds & Interfaces 18 (1996) 315-320

X3J3 are finalising input for a 1995 standard review, and suggestions are being discussed informally on the networks and in individual countries for the upgrade after that (Fortran 2000). However, changes introduced via this route are inevitably slow, and deletions from the language are the hardest of all to achieve due to a perceived need to cater for the massive stockpile of existing Fortran 77 (and earlier) codes.

In this paper, and intended successors, we attempt to broaden the discussion of the path Fortran devel- opment should take, by considering what is needed to bring Fortran into line with current best language practice for both serial and parallel architectures.

1.1. How to achieve more rapid change within the current evolutionary process

In accord with the IS0 and ANSI philosophy, we discuss deletions as well as additions to the lan- guage. Indeed, we are here concerned wholly with deletions needed to tidy the language.

This paper stops there: we describe what Fortran should have looked like in 1990. This means that we avoid discussing the merits of proposals for:

0 Minor changes to remove irregularities in the current language

0 Parametrised derived types 0 Exception handling 0 MIMD parallelism 0 Object oriented facilities

made by others for Fortran 95 and Fortran 2000. These, together with further but still overdue exten- sions will be addressed in a second paper.

2. Subset Fortran 90 and Extensions Annexe

2.1. Subset Fortran 90

An emphasis on deletions brings with it the ques- tion: what has this to do with the Standard? The answer is simple: we advocate the recognition by WG5 of a Subset Fortran. The Subset we have in mind excludes all the obsolete features; and our own version of the set of such features is described here.

No vendor is forced to implement only the Subset; but may do so if he feels it to be advantageous. Vendors implementing the full language are encour- aged, or required by the standard, to provide facili- ties to detect non-subset programs. The rationale is that it is easier to exclude a language feature from the Subset, than to remove it totally from the lan- guage.

2.2. The Extensions Annexe

The provision of an official subset of this kind goes some way, but not far enough, to provide an environment in which Fortran can progress fast enough to meet the needs of the users. It still remains difficult to obtain consensus on the addition of new features to the Standard; and rightly so, in our view, given the obvious defects in proposals made re- cently.

However, the difficulties have been over detail, rather than over requirements or even over outline solutions. We therefore also propose the adoption of an Extensions Annexe to the Standard. Into the Annexe goes those new features for which coherent proposals have been developed which have achieved reasonable consensus in X3J3 and WG5 over out- lines, but perhaps not yet over details, either because of perceived potential drawbacks or because of sheer lack of time. The appearance of a feature in the Annexe does not guarantee that the feature will appear, unchanged or at all, in a future Standard: it does however provide a halfway house for vendors to implement and for users to then experiment with. Programs using Annexe features are not guaranteed stability across Standards, but are likely to achieve better portability than if vendors had no model of the facility to draw upon.

We note that the HPF Forum already provide an Extensions Annexe: the “Journal of Development”.

3. Clean Fortran

We now assume that at least the Subset and preferably also the Extensions Annexe exist. Clean Fortran is a subset of Fortran 90, defined by deleting specific items; deletion in the rest of this paper should be taken to mean “this feature is not part of

L.M. D&es et al. / Computer Standards & Inte@aces 18 (19%) 315-320 317

Clean Fortran”. Clean Fortran is a candidate for adoption as Subset Fortran.

3.1. Potential extensions

In this paper we avoid populating the Extensions Annexe: we hope to return to that at a future time. But obvious candidate features to go into the Annexe are:

l allocatable array arguments l a modest form of exception handling 0 parametrised data types

for all of which quite detailed (and clean: cleanliness is a prerequisite for our Annexe) proposals already exist.

3.2. Deletions from Fortran 90

We believe that current language features should be deleted if they are no longer needed and/or lead to poorly structured or obscure programs. For For- tran 90, there is a measure of agreement over the list of features to be considered for deletion in Fortran 95 and in Fortran 2000. We give here the list that is to be considered as deleted instantly in Clean For- tran

Luckily, no reasonable person could wish for any of the following to remain in the language:

1. Features labelled as obsolescent in Fortran 90 This conservative list includes those features

which X3J3 felt were redundant even in Fortran 77; the rationale for deleting each is summarized briefly.

Arithmetic IF: is hard to read, leads to spaghetti Fortran, and has a functionality totally subsumed by the block IF construct. Replace by block IF. REAL and double precision DO control vari- ables and control expressions: were a mistake in Algol 60 which was remedied in Algol 68 and adopted in Fortran 77. The loop count depends upon roundoff error, leading to subtle non-porta- bilities. Use INTEGER control variables.

DO label loops: which have a functionality better spelt by replacement with DO _ . . END DO Alternate RETURN: and asterisk dummy argu- ments; are unstructured constructs usually better expressed by returning an integer code used in a CASE construct in the calling program (though sometimes calling clearly for the provision of exception handling: so much has been written and spoken on this topic in the past twelve months that as noted earlier we forbear to get into the game). PAUSE: is a harmless little construct which has no effect on the structure of a program, but which seems to have few friends and many detractors. It can be trivially replaced by a subroutine call, so we go along with deleting it. ASSIGN and assigned GOTO: are not only abominably unstructured, but explicitly violate strong typing which (on the whole) is supported even by Fortran 77. Replace by CASE. Assigned Format specifiers: have, we under- stand, fanatical adherents. But programs using them are prone to produce output which, though doubtless predictable, is hard to predict. The re- quired functionality, to dynamically change the format used for input or output, can be achieved in several less obscure ways: for example, using character formats and either array elements or pointers. cH edit descriptor: was replaced by character denotations in Fortran 77. The generation of pro- grammers which could count accurately enough to make the facility safe, is now largely dead (though one of the authors counts himself amongst them) so now it is time to delete the feature.

All of these features can be automatically and straightforwardly translated into better Fortran 90 constructs.

2. Features currently being considered for obsoles- cence

Shared DO termination: and termination on a The current IS0 and X3J3 discussions have led to statement other than END DO or CONTINUE: the following additional features being considered leads to programs with a control structure which for flagging as obsolescent in Fortran 95. While is not very clear to the reader. To this item we there is no certainty that any or all will be so add, although it was not in fact part of the obso- flagged, we hereby delete them all: as before, a brief lescent list in Fortran 90: rationale is included.

318 L.M. Delves et al. /Computer Standards & tnterfaces I8 (I 996) 315-320

computed GOTO: can always be trivially re- unlikely that they will need to generate more; they coded as a CASE statement with possibly a GOT0 also own a substantial number of programs on in each case leg (though this rephrases, rather paper tape, and welcome the ability to use free than removes, the spaghetti). We do not contem- source form should they ever need to edit these plate deleting GOTO. using their hand five hole tape punch. ENTRY: multiple entry routines represent built-in spaghetti: worse than causing the user to write spaghetti due to lack of facilities. They have been used in the past for several purposes: 0 to provide a mechanism for initialising data

needed at subsequent calls. The MODULE provides a much better way of doing this: alternatively, internal procedures accessing global variables will do if the routine is only needed locally.

All of these features can also be automatically removed from a Fortran 77 program, though with varying difficulties attached to the removal.

3. Other irregular features

l to emulate related procedures with differing numbers of parameters. This can now be achieved via the use of optional parameters.

0 to provide a partial simulation of a package of procedures all sharing a global data space. This is much better achieved by a MODULE.

But there are other “old” Fortran features which are widely regarded as irregular (and undesirable). Their absence from the official list of obsolescent features relates more to committee caution allied with continued wide use, than to technical common- sense. We discuss “wide use” below; here, we merely delete the features, with reasons:

EQUIVALENCE: There is nothing wrong with wanting to provide an alternative name for a variable:

Statement functions: are logically made redun- dant by internal procedures - no sympathy for the few character strokes saved by using statement functions. Nor for the (alas, usually misguided) belief that statement functions will be in-lined: if there is a need for forcing in-lining, it should be done via a compiler directive, ie outside the lan- guage. DATA in amongst executable statements: de- manding a tidy structure is no real hardship to the user, and a help to the compiler writer (and to other readers of the code). Assumed length character functions: these go along with Assumed size and explicit shape arrays: and CHARACTER* declaration: Assumed size ar- rays were a Fortran 77 kludge, and can be better replaced by assumed shape arrays (“proper” ar- rays in the notation of most other languages ex- cluding Cl. CHARACTER* was another kludge: previous attempts to give flexible length string facilities without using dynamic storage, and without extending the facility to other datatypes, have led to character facilities being one of the most irregular parts of Fortran 90. Fixed source form: the authors own a large number of (used) punched cards, but feel it is

0 REAL a; REAL, DIMENSION(lOO)va; EQUIVALENCE(a,va(lO)) can be viewed as achieving this. However, EQUIVA- LENCE(a,va(i)) is usually what is needed really; and the POINTER facility can provide either, while EQUIVALENCE can only pro- vide the effect of the first: REAL, POINTER::aa; aa = >va(lO)! or va(i1

0 But the prevalent Fortran 77 use of EQUIV- ALENCE to break the typing rules of Fortran 77 and its predecessors, and (worse) to force implicit sharing of names via a chain of equivalences, has been a great way of making obscure errors in Fortran for many years: it is time to remove the cause, and there is now no excuse to keep it: any arguments based on efficiency of code generation now fail: EQUIVALENCE is a barrier to optimisation, especially on non-homogeneous memory ar- chitectures. Those who really need to retype some space for some low (level) purpose, can do so cleanly and explicitly using TRANS- FER. Arguments based on re-using workspace have had a hollow ring for many years; dy- namic storage allocation in Fortran 90, and virtual memory, remove them totally.

COMMON: COMMON has been widely used to:

L.M. Dell es et 01. /Computer Standards & Interfaces I8 (1996) 31.5320 319

Provide a global dataspace without using ex- cessively long argument lists. This can be better achieved using MODULE to make re- usable workspace available. No longer neces- sary Provide implicit (and very hard to find) EQUIVALENCE and retyping facilities, via the use of versions of common blocks with differing structures in different routines. It is difficult to say how best to do this without COMMON. But it is not difficult to be sure that it is better not done, and the language is better if it is not do-able. Provide variables which change their type dynamically (EQUIVALENCE provides this too). This is a defensible thing to wish to do. It is provided in other languages via UNION types or variant records: so we introduce an appropriate mechanism in a later paper. There is now no need for COMMON to achieve its clean effects, and no easy way of restricting its use to be clean anyway. It is a major barrier to optimisation on modem ar- chitectures. It is one of the prime reasons why Fortran 90 still has to talk about storage units, and demand that a LOGICAL variable can be forced to occupy a byte, or even several. Out it goes.

SEQUENCE and other forms of storage associ- ation: There are a number of places in Fortran 77, and alas more in Fortran 90, where the program- mer is allowed (or forced) to write code which assumes a specific storage allocation mechanism in the compiler. Examples are: 0 When passing assumed size arrays. As a

result, Fortran 90 has contexts in which an array section is not an array. My my.

0 More generally, when relying on the lack of parameter type checking in the calling of external procedures (especially when passing arrays of one rank and interpreting them as of another rank).

l When using COMMON and EQUIVA- LENCE.

0 When specifying the SEQUENCE attribute, introduced specially into Fortran 90 in an apparent attempt to sabotage good program- ming practice for a further 25 years

0 More charitably: to provide an easier inter-

face to C and maybe other languages. But such interfaces should be made via a mecha- nism explicitly provided for the purpose, not via a mechanism which is a bit of help for some classes of parameter and none at all for others.

Previous deletions get rid of most of these. We add the further deletion: SEQUENCE is removed. FORMAT statements: FORMAT statements have a long history; and formatted I/O is one of the strengths of Fortran. Its richness and versatil- ity make it a (relative) pleasure to use. But la- belled FORMAT statements are no longer neces- sary, since character string formats can be used; and the use of labelled FORMAT statements, together with the quite common convention of getting them all out of the way in a group at the end of the code, make it hard to follow the expected layout of data. So we delete them.

3.3. The effect of these deletions

There now, that’s better isn’t it? Subset Fortran is easier to implement, to use, and to teach than full Fortran 90.

Won’t the deleted features be missed? Well, they aren’t really deleted of course - just not part of Clean Fortran. Let us repeat the rationale for this:

0 Removing dead features and irregularities makes the language easier to learn and to use.

0 It also makes compilers easier to write. 0 And it makes optimisations easier.

But there is the fear that existing users will not accept the deletion of “favourite” constructs. To which we reply: 0 Removing features from a subset, and even

from the standard, is not equivalent to removing them from compilers; vendors remain free to support any and all features, whether new or old, which they believe their customers want and which they feel will give them a competi- tive advantage. This includes features (example: REAL’4) which are not even part of the For- tran 77 standard.

0 Existing codes can be transformed automati- cally to remove dependence on all of the fea- tures we have deleted.

l Keeping a dead weight of old features is a sensible way to ensure that the current genera- tion of Fortran programmers is the last.

320 L.M. Deices et al./ Computer Standards & Interfaces I8 (I 996) 315-320

4. Putting money on it

This paper started life as an academic exercise. But, if the proposals are valid, they should make commercial sense too; users are there to vote on both de facto and official standards. Over the two year gestation period of the paper, both Lahey and NA Software have followed its advice to the logical conclusion: commercial compilers which implement the spirit, and indeed most of the letter, of this paper.

4.1. L.ahey ElfPO compiler

This is a version of the Lahey compiler which implements a subset of Fortran in which: 0 All features identified in the 1990 Standard as

obsolete, and indeed all identified as obsolete in the 95 standard save for assumed length, have been deleted.

l Alternative ways of doing the same thing have been reduced, leading to further deletions.

The full list of deleted statements is: ALLOCATABLE Alternate Return Arithmetic IF ASSIGN Assigned GOT0 BLOCK DATA COMMON Computed GOT0 CONTINUE DATA DIMENSION DOUBLE PRECISION ENTRY EQUIVALENCE EXTERNAL INCLUDE INTENT INTRINSIC PARAMETER PAUSE POINTER SAVE Statement Function TARGET

Note that the ALLOCATABLE, POINTER, PA- RAMETER, DIMENSION, SAVE and TARGET at- tributes can still be declared in a type statement.

In addition, the following features are deleted:

Fixed source form Implicit typing; an IMPLICIT NONE statement is

required Assumed size arrays DO with label; termination on an action statement DO with non-integer parameters Branching to ENDIF from outside the IF block Specific intrinsic names

together with a number of smaller restrictions all imposed to aid cleanliness without affecting expres- siveness.

4.2. N.A Sojhvare Fortran 9OPlus

The NA Software compiler is available in Developer and Personal versions. Both support the Clean For- tran aims directly:

0 Some of the “instant deletions” listed above have been implemented irrevocably: ASSIGN, ENTRY and alternate RETURN are not sup- ported at all.

0 Facilities are provided for flagging (nearly) all of the other “deleted” features, either as a Warning or as an Error; any Fortran keyword can be flagged, the list being specified by the user via an editable ascii file. IMPLICIT NONE can be set as the default via a command line option.

The aim has been to make Clean Fortran available for new users without removing the ability to accept obsolete codes unchanged. The default setting of the configuration file produces a warning whenever any keyword labelled as obsolete in Fortran 95 is used; and a Fatal Error should a keyword not implemented at all be encountered.

5. The moral

We would not take this route unless we believed in the message of this paper: the future of Fortran depends upon it evolving faster than it appears to be doing; and a mechanism for not only allowing, but encouraging this is urgently needed.

Acknowledgments

This work was supported in part by the CEC within Esprit projects Supernode II and PPPE. We are grateful to Lawrie Schonfelder for his interest and for helpful discussions on many aspects of For- tran 90 and of its future direction.

Reference

[l] Fortrun 90: IS0 Standard ISO/IEC DIS 1539 (1991).