Backward Compatibility
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away." -- Antoine de Saint-Exupéry
The Fortran standards committee generally refuses to break backward compatibility when Fortran is updated. This is a good thing (take that, Python), and code written decades ago can still be compiled fine today. However, over the years, various old features of the language have been identified as "obsolescent", namely:
- Alternate return
- Assumed-length character functions
CHARACTER*(*)
form ofCHARACTER
declaration- Computed
GO TO
statement DATA
statements among executable statements- Fixed source form
- Statement functions
ENTRY
statement- Labeled
DO
loops [will be obsolescent in Fortran 2015] EQUIVALENCE
[will be obsolescent in Fortran 2015]COMMON
Blocks [will be obsolescent in Fortran 2015]BLOCK DATA
[will be obsolescent in Fortran 2015]
And a small set of features has actually been deleted from the language standard:
ASSIGN
and assignedGO TO
statements- Assigned
FORMAT
specifier - Branching to an
END IF
statement from outside itsIF
block H
edit descriptorPAUSE
statement- Real and double precision
DO
control variables andDO
loop control expressions - Arithmetic
IF
[will be deleted in Fortran 2015] - Shared
DO
termination and termination on a statement other thanEND DO
orCONTINUE
[will be deleted in Fortran 2015]
In practice, all compilers still support all the old features (although special compiler flags may be necessary to use them). Normally, you shouldn't use any of this junk in new code. But there is still a lot of legacy FORTRAN 77 code out there that people want (or need) to compile. However, as I've shown many times in this blog, updating old Fortran code to modern standards is not really that big of a deal.
biga = maxval(a)
in modern Fortran.When the next revision of the language (Fortran 2015) is published, it will mark the first time since Fortran was first standardized in 1966 that we will have two consecutive minor revisions of the language (2008 was also a minor revision). The last major revision of the language was Fortran 2003 over a decade ago. There still is no feature-complete free Fortran 2003 compiler (although gfortran currently does include almost all of the Fortran 2003 standard).
Personally, I would tend to prefer a faster-paced cycle of Fortran language development. I'm not one of those who think the language should include regular expressions or a 2D graphics API (seriously, C++?). But, there are clearly potentially useful things that are missing. I think the standard should finally acknowledge the existence of the file system, and provide intrinsic routines for changing and creating directories, searching for files, etc. Currently, if you want to do anything like that you have to resort to system calls or non-standard extensions provided by your compiler vender (thus making the code less portable). A much more significant upgrade would be better support for generic programming (maybe we'll get that in Fortran 2025). There are also many other feature proposals out there (see references below).
See also
- Fortran Feature Proposals – at the Fortran Wiki.
- E. Myklebust, Feature Proposals for Fortran – The Complete Set, ISO/IEC JTC1/SC22/WG5 N1972
- C. Page, "Suggestion: Improved String-handling in Fortran", October 1, 2015.
- V. Snyder, "Units of Measure in Fortran", N1970, April 22, 2013.
- S. Lionel, "The Future of Fortran", March 27, 2015