Why I haven't moved (yet ?) to f90 or f95

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 f77 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 :

• 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 CHARACTER(LEN=80) STRING 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 type ARRAY(n)
• 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 IDL's xINDGEN.
• pointers
  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 pointer==>target

  ---

• 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 RETURN
• CONTAINS statement
  Usage of this separator for internal subprograms is unclear. How does this compare to the old "statement functions" (still supported) ?
• Modules
  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 compiler-dependent way.
• pointers as argument
  Usage of pointers as arguments (also to functions) and the TARGET attribute are confusing
• 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
  Overloading is complex, but can be useful to define "generic" shortcuts to functions on structures.

  ---

• 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")
• initialization
  Similarly the notation which initializes a variable in the type/dimension statement is less legible than the old DATA statement.
• PUBLIC and PRIVATE statements
  are confusing
• 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 good thing

  ---

• 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 arbitrary content.
• 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.