Why I haven't moved (yet ?) to f90 or f95
programming style and
habits formed and stabilised
quite a while ago.
For a while I moved around quite a bit and worked in different places on different systems (even different systems in the same place),
therefore I grew up with concerns about portability, learned to recognise
system-dependent features from
standard features, learned to avoid really
system-dependent features, specially when they were just useless cosmetics,
and learned which extensions to the standard were instead really useful
and/or widespread (the two things not necessarily coincident, so I learned how
to work around these, e.g. for INCLUDE file names).
In the mid '80s, when we were developing
XAS we were eagerly
concerned about portability, had to define a common subset for a number of operating
systems, and hoped that the Fortran 8X standard would appear and consolidate
soon and incorporate just those useful common subset of extensions.
However we realized that was not so likely to happen, since, for instance, I was
taught f66 during my University courses in the late '70s, and I first met f77
compilers around 1983 !
This perhaps could be expected !
When f90 came out, it was too late for us, I had developed a consolidated set of styles,
idioms and tools, which I had not the time to change ... and also major OS vendors were not
offering a safe-and-stable (or any) f90 compiler promptly.
Nevertheless I instigated our librarian to buy Metcalf & Reid's book "Fortran 90 Explained"
and read it (I traced from the library stamp this occurred in 1993 ... and now is 2000),
but the new standard
was quite unlike what I expected :
Below I'll list my doubts (and eventually considerations and potential solutions),
in an order which more or less follows Metcalf & Reid's
- there were many totally new, exotic and unclear features
- some items were standardized in a way unlike the previous widespread extensions
- some items expected to be standardized were missing
- there was the impression some modern Atatürk was trying to coerce Fortran
programmers to a dramatic change in style (like when the Turks were forced to go
from the Arabic to the Latin alphabet).
This sign and the red colour indicates
features for which I express a negative opinion,
this sign and the green colour indicates
features for which I express a positive opinion,
this sign and the orange (amber) colour
indicates features to which I am indifferent (but do not regard as necessary) or for
which negative and positive elements balance, or which are somewhat negative but not compulsory.
Present date is 07 Sep 2000
- change of source form
While overcoming the 72-char limit could be welcome
I find rather annoying the use of an ampersand at end of line
instead of the old character in column 6 (which is also clearer to read)
- change of comment format
While accepting inline comments preceded by ! is endorsing a common
extension, there was no reason to introduce the annoying
renounce to the old C and * in column 1 for comment lines.
Also one could expect to endorse also the common extension of D optional debug compilation
which did not occur
- multi-statement lines
While instead it was standardised the poorly legible practice of
putting more statements on same line with a semicolon.
- KIND data types
While one could have expected an endorsement of the common
extension of the INTEGER*n and REAL*n notation (which in some cases like
handling external telemetry records is really useful), the awkward and unclear
KINDs were introduced. It has to be noted that the default KINDs are
not standardized among different compilers !
- CHARACTER(LEN=nn) notation
I do not see the reason to introduce the more verbose notation
with respect to the older CHARACTER*80 STRING or CHARACTER STRING*80 (since f77
shall remain supported as a f90 subset, this introduces more redundant features to support, in
contrast with the policy of "obsolescent statements")
- notation for derived data types
The introduction of derived data types is positive, they correspond to
what are called structures in other programming languages or records in some f77
extensions (which I avoided because not widespread enough). However a curious
and poorly legible STRUCTURE%COMPONENT has been devised, instead of the notation
STRUCTURE.COMPONENT which one could expect for analogy with C, IDL and f77 extensions.
- syntax of the type and dimension statements
I do not see the reason to introduce the more verbose notation
type,DIMENSION(n) :: ARRAY with respect to the older compact notation
- subscript arrays
The introduction of subscript arrays ARRAY(LIST) and
array sections ARRAY(n:m)is definitely positive (in IDL style)
- array constants
The introduction of array constants (/v1,v2,.../) is definitely positive
despite the notation is not quite happy, wrt e.g. the one used by IDL. Also
implicit-DO constants (/I, I=1,n/) are handy and more flexible than
The introduction of the notation of pointers is confusing. Use of this C-like
construct should not be encouraged in non-system programming, and the old %LOC %VAL extensions were
probably appropriate enough to deal with passing arguments to exotic system routines.
- alternate notation for logical operators
The alternate notation > < ... besides the old .GT. .LT. ... is
unnecessary and redundant, specially considering the "obsolescence principle"
- interfaces for operations on structures
The introduction of INTERFACE blocks is a useful way to write legible
shortcuts to operations on structures (however its use should be reserved to few specialised cases).
- array operations
The introduction of array assingments and operations of compact form A=B+C is a
positive way to improve legibility and simplify the code
(in IDL style)
- pointer assignment
See comment above on pointers for this confusing notation
- IF block names
The introduction of names for block IFs is a
possibly useful but unnecessary notation (indentation and
eventual usage of labels was enough).
- CASE constructs
The SELECT CASE statement is a
slightly more legible notation with respect to the
pre-existing and equivalent computed GOTO.
- changes to DO statements
The introduction of names for DO loops is an alternate
possibly useful but unnecessary notation (indentation was
confusing but usage of labels was enough). Aslo the EXIT and CYCLE
statement provide a legible but unnecessary alternative
to the pre-existing and equivalent use of GOTO. Introduction of the "forever" DO
is a somewhat handy shortcut.
- program unit END statement
The introduction of the (sub)program name in the END statement is an
unnecessary though perhaps sometimes more legible feature.
Also I do not like the practice of using END as
executable (and not just as a marker for the compiler) equivalent to STOP or
- CONTAINS statement
Usage of this separator for internal subprograms is unclear.
How does this compare to the old "statement functions" (still supported) ?
The main strong doubt about the usage of modules instead
of INCLUDE, COMMON
and BLOCK DATA is that it is nowhere specified who
handles them (the compiler or the loader) and how they are dealt with, wrt
library routines : the suspicion is that those things could be dealt with in a
- pointers as argument
Usage of pointers as arguments (also to functions) and the TARGET attribute are
- argument intent
The optional specification of the intent of arguments is a
useful way of standardizing the documentation of
the characteristics of the argument, and could possibly prevent errors
- usage of INTERFACEs
The usage of INTERFACE blocks for functions passed as arguments seems
redundant and exceedingly verbose wrt the old notation
of a plain EXTERNAL declaration.
- optional arguments
The possibility for a subroutine to have OPTIONAL arguments (and the
usage of the PRESENT test) is
positive (in IDL style). Also keyword arguments are
in IDL style but may lead to an heavy notation.
- recursive procedures
Can be rarely useful
Overloading is complex, but can be
useful to define "generic" shortcuts to functions
- automatic array notation
The notation type,DIMENSION(:) ARRAY is less legible
then the old type ARRAY(*). However the possibility of having work arrays of
variable dimension DIMENSION(SIZE(arg)) WORK is useful
- operation on arrays
Elemental operations on array are very useful. The fact that
a separate interface block is necessary to define interfaces for operations on arrays
of structures is complex but useful
- allocatable arrays
Are definitely useful.
- WHERE statement
Is useful, although the notation of IDL (creating an array
of subscripts) would have been better
- array constructors
Are a useful extension to the array constant and implicit-DO
array constants, although the RESHAPE notation to construct n-dimensional
arrays is complex
- IMPLICIT NONE
Has finally been standardized : however equivalent results
could be achieved externally of the program using specific compiler switches !
- named constants
The notation type, PARAMETER :: VAR=value is
more verbose than the old simpler
PARAMETER (VAR=value) (again contradicts the "obsolescence principle")
Similarly the notation which initializes a variable in the type/dimension statement
is less legible than the old DATA statement.
- PUBLIC and PRIVATE statements
- again on derived types
I'd expected derived types to be introduced not only for structures, but
also for exotic data types like bit arrays, integers with an arbitrary
number or bits, or the deprecated unsigned integers, but this
did not occur
- intrinsic functions
The list of new intrinsic functions must be carefully studied but appears to
provide many useful new functions, particularly for
strings, numeric inquiries, bit manipulation, TRANSFER, arrays and matrices,
and date-time without altering the syntax of the old usual ones
- i/o statements
I do not like the preservation of the VAXism PRINT
and READ instead of the more general READ(*,*) WRITE(*,*) notation
- carriage control still in
The usage of the first character in an output record for carriage control is really
obsolete and would have been an obvious candidate for deletion
- non advancing i/o
The ADVANCE=NO construct is a good way of
standardizing this useful feature in output. I fail to see
however the usefulness of the other features for non advancing input
- hex and octal format
The standardization of the edit descriptors for hex, octal and binary formats is a
- OPEN statement
It is a pity that the semantics of opening a file with NEW and OLD status were
not fully standardized among OSs, however the introduction
of the REPLACE status is a step forward
It is also a pity that the standard does not specify that
RECL must be in bytes, and leaves the old, deprecated liberty to OSs
- OPEN with append
The possibility to specify POSITION=APPEND is good
- INQUIRE statement
I imagine I cannot blame Fortran if an INQUIRE by RECL or NEXTREC
does not work on a non-connected file in Unix where files
unfortunately do not have recl and direct access attributes.
- why deprecate EQUIVALENCE ?
I do not like at all the deprecation of the EQUIVALENCE
statement which is extremely useful when dealing with external telemetry records with
- why deprecate COMMON ?
I do not like at all the deprecation of the COMMON
(and associated BLOCK DATA)
statement which is extremely useful in a number of situations, and does not has the
obscurity of modules.
- why deprecate ENTRY ?
I do not like the deprecation of the ENTRY
statement which is sometimes useful when similar routines share lots of data and code.
- INCLUDE statement
It is a good thing that such statement, which is simple
and useful, is now in the standard
- true obsolescent features
I do agree to regard as obsolescent the arithmetic IF,
the DO with real stride, the assigned GOTO (although it was of some use with some
specific compilers allowing to jump into error handler subroutines, this was so
compiler dependent ...), the branch to ENDIF, the PAUSE
and Hollerith descriptor
- alternate RETURN
I do not agree with the obsolescence of alternate return
from subroutines, which allow to write more legible code in case of error handlers.