technical deficiencies with fortran 90

ELSEVIER Computer Standards & Interfaces 18 (1996) 295-302

Technical deficiencies with Fortran 90 J.L. Schonfelder

Computing Sewices Department. University of Liverpool, PO Box 147. Ltuerpool M9 3BX. UK

Abstract

A personal view of the major technical deficiencies of Fortran 90 is presented. The defects are listed and described in what might be interpreted as a set of requirements for a future language revision. The list reflects the view of one of the active designers of Fortran 90 and one who is the head of a major academic computing service whose users are slowly becoming significant users of Fortran 90. The views are therefore conditioned both by individual observations and by the observed reactions of users starting to use Fortran 90 in anger.

Keywords: Fortran 90: Language defects; Programming constraints

1. Introduction

Fortran 90 is good language. It is not, however, a great language. It fails to “succeed in having greatness thrust upon it” by virtue of a few deficiencies which irritatingly preclude some wholly desirable programming approaches, approaches that are tanta- lisingly almost supported. These deficiencies will be outlined below.

Some of the deficiencies of Fortran 90 arise because of a lack of appreciation by those of us involved in its design of the full implications of some of our decisions. These have become more obvious now we have started to gain experience in teaching Fortran 90 to real users and also in trying to support their use of the language in writing significant programs. Other defects are the result of some of the unfortunate political compromises that were necessary to enable Fortran 90 to appear at all, and some were the result of simple drafting fatigue.

The main body of this paper attempts to outline a personal view of what are the main deficiencies in

Fortran 90. It is a source of considerable sadness that most of these deficiencies are to remain as such in the proposed revision, Fortran 95, whose content has now been determined. They will therefore continue to debar Fortran from becoming the great language that it so easily could; greatness is thus postponed until the third millennium.

2. Fortran 90 deficiencies

The two most significant modernising features of Fortran 90 are its facilities for handling arrays as genuine first class objects, and its semantic extensibility. Only APL comes close to having a compara- ble capability for array handling, and Fortran 90 achieves its capability without also following APL and turning into a write-only language. In its semantic extensibility Fortran 90 comes close to, and in some ways surpasses, languages like Algol 68 and Ada. However, it contains some significant ad-hoc restrictions and irregularities which make it irritat-

0920-5489/96/$15.00 0 1996 Elsevier Science B.V. All rights reserved PII SO920-5489(96)01005-7

296 J.L. Schonfelder/ Computer Standurds & Interfaces I8 (1996) 295-302

ingly difficult if not impossible to fully exploit some of the expressive power to the full. A semantic extension is almost possible that builds facilities for a derived type which mirror those defined intrinsi- cally for one of the built-in types. The problem is in the “almost”. Many of the deficiencies listed below are those that cause this inability to do a complete job of data-abstraction/semantic-extension.

The most serious deficiencies are those of omission, although there are a few defects that are clearly ones of commission. In this overview we will list a few of both types.

2.1. Parameterised types

The most serious of the defects of omission, in my opinion, is the lack of parameterised derived types. This was a capability which was lost as the result of the “simplifying” compromises that led to the final definition of Fortran 90. The lack of this capability results in a gross linguistic irregularity. All the intrinsic types are parameter&d but none of the user defined types can be. This defect greatly weak- ens the semantic extensibility of the language.

Intrinsic types have two different varieties of parameter. The first, which is a feature of all intrinsic types, is the KIND parameter. This parameter is used to select the physical representation of the datatype. The kind parameter is required to be statically determined (it must be known at compile time). For integers it is used to select which of the available integer ranges is used. For real data it selects which precision/range is to be used. Crudely the KIND selects by parameter which of single, double, etc. is used for a particular object, i.e. how many bits are to be used in the representation. Or in the case of characters, KIND selects which possible character coding is to be used.

This is essentially a generalisation of the well known * 4, * 8, etc. extension widespread in Fortran 77 implementations except the syntax is regularised and made extensible and the integer selector is made parameterisable rather than being a fixed literal. This enables source code to be written which is parameterised as to data representation.

The second sort of parameter is the length parameter of the character data type. This parameter is very different in nature. It does not select among different

physical representations of data. It provides a value which controls the number of times an atomic entity is repeated, in effect how often a loop might need to be iterated. To this extent such a parameter is not necessarily static. In fact character length can be determined dynamically in ways similar to those permitted for array bounds in Fortran 90.

The absence of both types of parameter for user defined types has serious restrictive consequences. The lack of parameters of the length variety means that in the use of derived types Fortran 90 suffers from all the well known disasters of Pascal in that types with array components of necessity have the sizes of the arrays built into the static definition of the type. This means that every time a different size is required for an array component, a different type must be used. For example,

TYPE MATRIX REAL :: element (10, 10)

ENDTYPE MATRIX

order of the matrix, 10, in such a type is fixed by the type definition. All objects of type matrix are of necessity of the same order, in this example 10. If two different matrix orders were required in the same program they have to be coded as two separate types. Say,

TYPE MATRIX-3 REAL :: element (3, 3)

ENDTYPE MATRIX-3

TYPE MATRIX-4 REAL :: element (4, 4)

ENDTYPE MATRIX-4

this then requires all the operations and procedures for manipulating matrices to be duplicated, one set for MATRIX-3 type objects and another set for MATRIX-4. There is no way of expressing the fact

that a matrix is an object represented by a square array of reals which is parameterised by a quantity called the order that determines the number of ele- ments in any row or column. Because of this lack it is not possible to declare objects of type matrix some of which have, say, order 3 and others that have, say, order 4. It is not possible therefore to write a proce-

J.L. Schonfelder/ Computer Stmdards & Inrrrfucrs 18 (1996) 295-302 297

dure that can perform a matrix operation for any order of matrix. This deficiency renders Fortran 90’s otherwise quite powerful derived type facility virtu- ally useless for much serious mathematical use involving objects such as vectors and matrices.

The lack of static kind style parameterisation of derived types makes it clumsy to use parameterised intrinsic types and derived types together. A typical situation occurs when a library of facilities is being produced which is meant to be generic over precision. If only intrinsic type objects are involved, the library can easily be produced in such a way that the user can parameterise the intrinsic type arguments. If the kind parameter for such arguments is changed the program correctly adjusts and selects the changed generic variant of the library procedures. However, if a derived type was convenient, as it frequently is to group some of the arguments or if some of the arguments were best represented by a derived type such as a vector, the lack of parameterisation for the KIND of this derived type means that an explicitly different type with a different name must be used for each available kind-value. Hence, rather than the whole program being parameterised, we are back in the archaic error prone process of searching through the source for any derived type and making an explicit change in the local code. Again this simple lack very seriously emasculates the use of the otherwise powerful derived type facilities.

The sad thing about this deficiency is the compar- atively simple addition to Fortran 90 needed to com- pletely correct the defect. Earlier drafts of what became Fortran 90 contained such functionality and proposals have been made by the author to the relevant committees that would effectively reinstate derived type parameterisation along these lines [2]. Unfortunately, the currently accepted plan for For- tran 95 does not include implementation of these or any other proposal to correct this deficiency. This glaring irregularity must wait until next millennium for its removal.

2.2. Allocatable array restrictions

When it was finally decided to include a full pointer facility in Fortran 90, the facility for allocatable arrays previously part of Fortran 8x was removed. The grounds for this was that all the func-

tionality provided by allocatable arrays could be obtained by the use of a subset of the facilities provided by pointers. This was and remains true. However, it was then recognised that the restricted set of capabilities provided by allocatable arrays when dynamic memory use was all that was needed would be simpler for many users to employ, would lead to fewer errors (pointers are notorious for caus- ing program bugs), and would allow much greater code optimisation. As a result a restricted allocatable array facility was reinstated. Unfortunately, the committee was at this stage running into drafting fatigue. The resulting allocatable array facility is too restricted.

In Fortran 90 we have a facility that does not allow derived types to have allocatable components. It does not allow dummy arguments to be allocatable, nor can function results be allocatable. In each of these contexts a pointer to an array must be used even where dynamic address manipulation is not needed and the pointer is only to ever be associated with space by allocation. This is now recognised be seriously irregular and to lead to:

0 unfortunate constraints on optimisation, and 0 propensities for programs that leak memory.

This latter feature is largely a result of an interaction of this defect with some unfortunate choices for defaults involving pointers.

As a simple example of some of the consequences, the string type used in the illustrative example for the auxiliary standard for varying length strings ’ uses a derived type,

VARYING-STRING

CHARACTER, POINTER :: chars(:)

allocatable components are not allowed so the component is a pointer to an array of characters. This

’ Ref. [I] defines facilities for handling varying length character strings. ‘Ike standard defines the functionality via a derived-type and module interface and it contains a module written in Fortran 90 which is one possible implementation of the standard.

298 J.L. Schonfelder/ Computer Standards & Interfuces 18 (1996) 295-302

means that the processor has to assume that there is the possibility of constructs like

chars =>str2%chars

may cause indirect association of space for the actual value of a string. This could result in two different string variables actually referring to the same space as well as value. This precludes a number of com- mon optimisations.

Since pointers are by definition created in an undefined state, it is not possible to deallocate a string value prior to it being given a new value. The result is unavoidable memory leakage whenever a string variable is given a new value. This is helped but not removed if the processor implements a garbage collector.

Both of these problems are removed if the type could be defined as,

VARYING-STRING CHARACTER, ALLOCATABLE ::

chars ( : )

For such a type the indirect and multiple address- ing of actual string values is no longer possible, thus removing a significant constraint on optimisation. Also since allocatable arrays are always created in a deallocated state, an application can safely test any existing string variable before it is given a new value and free any space currently in use. This greatly reduces the memory leakage problems.

Along with this capability it would also be necessary to add the regularising facility to permit allocatable dummy arguments and allocatable function results. Both these functionalities were deliberately, but mistakenly left out of Fortran 90. Again the argument was that the functionality was available by use of pointers. However, for very similar reasons to those outlined above for allocatable components, allocatable dummy arguments and function results which do not allow the possibility of dynamic aliases merely dynamic size, permit very much more opti- misable programs. For the same reason such facilities also reduce the risks of error which are inherent in the use of pointers.

2.3. Pointer initial status

This defect was mentioned above. Fortran 90 chose by default to have pointers created in an undefined state. New pointers have no defined initial state. This compares irregularly to allocatable arrays where the initial state is defined to be deallocated. This problem is compounded by restrictions which make it impossible for the user to specify any initial state for pointers. In many (in my opinion most) applications it would be desirable for the user to be able to specify that the pointer should be initially disassociated.

This defect is being corrected in Fortran 95. The restrictions which stop users specifying initial state are to be removed and in addition facilities are introduced to allow the user to specify a default initial value/state for components of a derived type.

2.4. Condition and exception handling

This was one of the features of Fortran 90 that was discussed at great length at various times by the committee. A number of different proposals of various levels of generality and complexity were consid- ered but in the end none managed to make it into the final definition. At one fairly early stage a very ambitious fully asynchronous event handling facility was looked at but the size and complexity of this was simply too off-putting to too many of the committee members to stand a chance of acceptance. This was followed by various attempts to produce simplified systems that would deal with at least numeric and other program exception conditions. One or two of these proposals potentially provided an adequate mechanism for dealing with this more limited problem but again these proposals were lost in the political compromises that became necessary to achieve sufficient consensus to produce the standard.

This area is clearly one that is difficult to handle in the technical committees. It always seems to run into the same political/technical dichotomy. There are those on the committee who basically only want a very limited facility that handles just the sort of numerical exceptions for which most processors provide some type of hardware support. On the other hand there are those who become very unhappy at

J.L. Schonfelder / Cornpurer Smulord.\ & Inrerfirces I8 (1996) 295-302 299

the sort of ad hoc language design that is inherent in such limited proposals. In practice, in spite of widespread agreement that an exception handling functionality is needed, it has so far proved impossible to find a design that can command a sufficient consensus to be adopted. This is as true of the Fortran 95 revision as it was of the Fortran 90. The latest in this long line of proposals is that due to Reid. 2

2.5. Derived type constructors

The derived type value constructor in Fortran 90 is an unlovely thing. It is essentially syntactically and semantically equivalent to an intrinsic function reference. However, it is seriously and unnecessarily restricted. Given a type definition and object declaration such as,

STOCK-ITEM Integer :: id, holding,

order-level CHARACTER(LEN=20) :: description REAL :: buy-price, sell-price

type (STOCK-ITEM) :: pencil the Fortran 90 constructor must be referenced as,

. pencil = STOCK-ITEM(12345, 1200,

144, & "HB pencils ", 0.35, 0.65)

the constructor reference has the form of a function reference but only the positional unkeyworded form of reference is permitted; this in spite of the fact that the effective interface is fully defined by the type definition and must be explicit at the point of reference. It would have been very much more user

'See Ref. [3]. Original suggestion evolved during committee consideration until the last version that was rejected by X3J3 was: X3J3 paper 94.258r4, (Aug. 1994), “Enable Proposal”, J.K. Reid

friendly if function reference identity had been com- pleted allowing a reference such as,

pencil”“=“” STOCK_ITEM(id=12345,holding= 1200, &

order_level=144, description= ‘WB pencils ", buy-price=0.35, sell-price=0.65)

or perhaps the even more readable, pencil = STOCK-ITEM( description= 'HB

pencils ", id=12345, &

holding=1200, sell-price=0.65, & order_level=144, buy-price=0.35 1

a more logical ordering of the component expressions is produced using the reordering made possible by use of the keywords in the reference.

It would have been much more friendly and regu- lar if the constructor had been defined as a generic intrinsic function whose interface was derived from the type definition. For example, with a simple type such as,

vector REAL :: a(3)

constructor has the effective interface, vector

FUNCTION <vecl>(a) ! vector from real array

REAL :: a(3) type(vector) :: <vecl>

ENDFUNCTION <vecl> FUNCTION <vec2> (a) ! vector from

integer array

INTEGER :: a(3) type(vector) :: <vec2>

ENDFUNCTION <vec2> !""and so on covering all the ar-

guments that are ""assignment

!""compatible with a size 3 default real array

Significant change in drafting would cause a minor change in implementation semantics but would have considerable benefits in usability and readability of derived type constructors.

300 J.L. Schonf~lder/Computer Standmds & Interfims IX (1996) 295-302

2.6. Complicated expression restrictions

Fortran 90 defines a complicated set of restrictions and classes of expressions that can be used in various different contexts. The text defining these is among the most opaque in the standard. Many of the committee members, including those who were involved in drafting this text have difficulty in sorting out exactly what the restrictions are as distinct from what was intended that they be.

Fortran 90 distinguishes five categories of expression:

0 constant expression, l restricted expression, 0 initialisation expression, 0 specification expression, and 0 genera1 expression. The concept of a restricted expression is only

used to help define some of the other categories. The other four categories are all defined due to there being contexts where these constrained categories of expression only are permitted.

Constant and initialisation expressions are constrained so as to be in principle statically evaluatable. Initialisation expressions are further constrained to be evaluatable using only a limited set of intrinsic functions, a set that might be expected to be available at compile time. Specification expressions have similar restrictions to initialisation expressions except that they may involve a limited class of variable primaries. These variable primaries are limited to those variables accessible as dummy arguments or accessible globally via use or host association. These restrictions on specification variables are reasonable since they correspond to those variables that could be expected have defined values at the time the procedure is invoked. The restrictions on the procedures that can be invoked in such expressions are not however any more reasonable than they are simple to comprehend.

Given that specification expressions will frequently be evaluated at run time there appears to be little genuine need to retain these complex restrictions. It would greatly simplify the description and the teaching of the language if specification expressions were merely general expressions which deliver a result of type integer. The classification of expressions could then be further simplified by reverting to

a single constrained restricted class, namely one that was so defined as to be guaranteed to be static.

2.7. Interface declaration

Fortran goes to great length to avoid the possibility of duplicate declaration of an object. The one exception is where that duplication is unavoidable but uncheckable. Where an interface block is used to declare the interface for an external procedure the actual definition of the procedure also declares the interface, but although the standard requires the two interfaces to be the same there is no way in general in which this can be checked by the processor. However the rules of the language are so designed that it is either impossible or illegal to have duplicate declarations of the interface for a procedure in all those cases where the identity of such declarations could be statically checked. This has a number of unfortunate consequences.

Firstly, to ensure that duplicate declarations are never produced or are flagged as illegal, quite a lot of fairly arcane and difficult text has to be included in the standard. This detracts from its readability and significantly increases the difficulty of teaching the language.

Secondly, it makes migration from Fortran 77 to Fortran 90 more difficult. One of the obvious steps careful users attempt when starting on this migration process is to make all procedure interfaces explicit. An obvious initial approach to this for an existing library of external procedures is to define a module in which the interfaces of all of the library routines are declared. The interfaces can then be made explicit in any program using the library by including the appropriate USE statement on this module. This is a very practical approach when all the external procedures are independent. Trouble arises when the routines in the library cross call each other and the interfaces for these cross calls need to be made explicit as well. The naive user is tempted to do the simple thing; simply add the same USE statement to each routine. Users are genuinely puzzled and not a few of them angry when the system objects on the grounds that this results in duplicate declarations; a given procedure has its interface declared in the library-interfaces module and also in its definition. One at least irate user has been known to retort when

J.L. Schonfelder/ Computer Standurds & Inte+ces I8 (1996) 295-302 301

informed of this “but they are the same, we produced the one by copying the declarations from one to produce the other just as it says in the book. It should be OK”. Nor are disgruntled users much placated by being informed that they can solve the problem by employing the ONLY clause on the USE in the appropriate manner. They are usually a little more resigned to the situation by being told that they can solve this problem if they put the source code of all the library routines into a module after a CON- TAINS rather than just the interfaces before it, but by this time the “helpdesk” duty programmer has had something of a hard time.

Thirdly, the restriction makes it difficult and messy to express those, admittedly rare, situations where the same external procedure is required in two different generic overloads at the same time. If duplication was allowed the same external interface declaration could occur in each of the generic interface blocks and provided they were identical there would be no problem. The program would be simpler and more readable. However, as it is now one generic block with the full interface has to be declared in a module and this accessed by USE into the program containing the other generic block. This second block is then accessing the interface via use association and hence can include the external procedure by a MODULEPROCEDURE declaration. This does not solve the problem when two separate modules both add the same external procedure via full interface declarations to different generic sets.

be defined as part of the generic interface block declaration. This is and should be a separate design task from the actual programming of the bodies of the specific procedures. However, when the specific procedures are implemented, often a process that is separated by time and place, and possibly in person from the overload interface design, the full interface detail is again required. In the one case the interface information and the interactions between a set of interfaces is significant. In the other the specific interface and its interaction with the code implement- ing the procedure is significant. Maintenance changes may be needed in either location but as the information is now actually held only in the specific procedure definition, changes which effect the overload design are especially difficult to make. There is a tendency for users to retain the full interface definitions as commentary within the generic interface blocks. However, since the consistency between this commentary and the actual definitions is not checked it tends to get out of step and thus becomes a liability rather than a help. Being allowed to have duplicate but statically checkable duplicate interface definition in both contexts would be of great benefit in assisting robust program development and maintenance.

2.8. Irregularities of the DIMENSION statement

Fourthly, finally, and most importantly duplication would be a valuable aid to both structured development and maintenance of large programs. Many such projects will depend on large modules of reusable code, particularly modules defining a semantic extension based on a data abstraction. When such modules are designed the primary task is to design the datatypes and the generic overload sets of operators and procedures that will provide for the manipulation of objects of these types. 3 In a large module of this type the interface definitions and the overload set designs can be quite involved. There is therefore a need for the full detail of the interfaces to

The DIMENSION attribute and the DIMENSION statement forms are not properly regularised. With the attribute form the array properties, bounds and ranks, are specified with the attribute. These array properties become the default for all the arrays being declared in the statement, although they can be overridden by different array property specifications attached to the individual arrays. In the statement form it is not possible to attach the array specification to the DIMENSION keyword. In the statement form all array properties must be specified individu- ally for each object. This is an irritating irregularity. If we must have a DIMENSION statement form at least it should have the same capabilities as the attribute form.

It should be possible to write a statement of the form

’ See the module illustrating a possible implementation of the 8t REAL :: a, b, i, j “Varying Length Character Strings” standard for Fortran [ 11. DIMENSIONC-N:N) :: a, b, i, j

302 J.L. Schonfelder/ Computer S:andards & Inter@es 18 (1996) 295-302

paralleling the attribute forms

REAL, DIMENSION(-N:N) :: a, b, i, j

As a personal stylistic preference I would always use the attribute form, but I can see that there may be some reason to employ a regularised statement form if a number of arrays with different types etc. are needed but all with similar array properties.

2.9. Detioed vpe I/ 0

The lack of proper facilities to extend the intrinsic I/O syntax and semantics to cover derived type objects is a major constraint on both proper data-abstraction/semantic-extension capabilities and will similarly constrain any attempts to extend these ideas further into “Object Oriented” programming.

It is perhaps a little unfair to castigate Fortran for punting in this area. None of the existing semantically extensible languages have provided for full abstraction of the I/O capabilities covering derived types. Algol 68, Simula, Ada and C + + all provide crude and rudimentary facilities in this area. Because of the largely procedural basis for all I/O in C/C + + it is probably easier for the user in these languages to produce an extension within a class library that come close to being a genuine semantic extension but this will in many cases not be all that simple an activity. In Fortran, with its statement based I/O the abstraction is essentially impossible.

This is clearly a very difficult area of language design. Solving this problem may require a major revision of the conceptual basis of Fortran I/O. It is, therefore, not surprising that the 8x committee punted the question, nor that the F95 revision committee chose to postpone the problem. Nevertheless, this remains a serious lack and a major constraint on the abstraction capabilities of the language.

3. Conclusion

A paper such as this, that is a compendium of dissatisfactions, irritations and perceived defects, might give the impression of a generally antagonistic

view of Fortran 90 as a language. This would be very far from the truth. This paper was the result of a commission to provide a paper on the defects as I saw them in Fortran 90. It must therefore have an overall negative appearance. This is unfortunate and misleading. As someone who has now done most of his programming for the past couple of years in Fortran 90, I can without equivocation say that I would not willingly switch to any other language. (I might be tempted by Algol 68 if I had a good compiler for my notebook PC but even there I think Fortran 90 would still win). The functionalities outlined above are those that I have felt the lack of when using the language. I live in hope that after the millennial revision Fortran 2ooO will contain most of these and more.

One final defect that increasingly worries me is the lack of windows support. As both a user and a service provider I am increasingly involved in working in a windows environment. This may be either X-windows or more frequently is the MS-windows environment. I and many other programmers would love to have a defined Fortran 90 interface which would allow us to easily write applications that interfaced comfortably and consistently with this general user interface environment.

References

[I] ISO/IEC 1539-2: 1994, Programming L.anguage Fortran,

Part 2: Varying Length Character Strings. [2] L. Schonfelder, Parameterised derived types, Fortran Journal,

6 (1) (1994). [3] SIGNUM. The ENABLE construct for exception handling in

Fortran 90, SIGiVllM Newsletter, 28 (4) (1993) 7-16. IFIP Working Group 2.5 (Numerical Software).

Lawrie Schonfelder [email protected]) is the Director of the Computing Services Department at the University of Liverpool. He was a founder member of the Numerical Algorithms Group and the original contributor of the special function approximation software. He has published in this area and in the areas of numerical software portability and the use of data abstraction techniques in software development. He has been a member of the IS0 Fottran technical committee since 1980 and was a member of the ANSI Fottran committee from 1983 through 1992. He was the principal author of the auxiliary Fortran standard on “Varying Length Character Strings”, ISO/IEC 1539-2: 1994, and he remains the project editor for this standard. He lectures regularly in Europe and Australia, on language standardisation and Fortran standards in particular.

technical deficiencies with fortran 90

Documents