ISO published the latest revision of the Fortran standard, Fortran 2023, on November 17. We’ve been working on this for five years, and it brings many new features, expansions of existing features, and fixes to text that was either wrong, ambiguous, or failed to define correct behavior. You can read John Reid’s excellent summary of The New Features of Fortran 2023, but I’ll highlight a few of them here.
- Past revisions have increased the number of continuation lines allowed, but we keep getting complaints that it’s not enough. Moreover, many people want to write source lines longer than 132 columns in free form, and that value hasn’t changed at all since Fortran 90. Now, a free-form source line may be up to 10,000 characters in length and the limit on continuation lines has been removed entirely, being replaced by a total statement size limit of one million characters. (This is primarily to benefit machine-generated source.) There are no changes to fixed-form source, which continues to be an obsolescent feature.
- Conditional expressions provide the ability to selectively evaluate one of two or more expressions based on a value. The syntax for this varies across various languages, but after intense debate, we selected something closely resembling many other languages using the ‘?’ character. An example would be
value = ( a>0.0 ? a : 0.0) . An important distinction is that
? is not an operator, but part of the syntax including the enclosing parentheses. Another is that, unlike other expressions in which operands can be evaluated in any order and to any degree of completeness. only the “true” case of a conditional expression is evaluated.
- A conditional argument looks like a conditional expression, but it selects an actual argument, which could be a variable, exactly as if that argument was specified directly. An additional feature allows you to select
.nil. as an indicator that an optional argument is not present.
- The C interoperability procedure
C_F_POINTER now allows you to specify lower bounds for the created pointer.
- A new
AT format edit descriptor automatically trims trailing whitespace from character values, and, answering many years of complaints and requests, it is now possible to control whether the “optional” leading zero in output of real values is included.
- A number of features helpful in enabling generic programming were added, such as
classof(), and a new syntax for using integer arrays for specifying subscripts, ranks and bounds of an array.
- “True” enumerator types that aren’t just another way of saying
PARAMETER, with features to make them interoperable with C enums.
- A new reduction specifier for
There’s lots more, and compilers are already adding support for some of these. Meanwhile, the committee has been taking user requests to make a list of features and changes for the next revision, which we informally call Fortran 202Y. Generic programming has been under development for five years now, and the model looks quite useful. We’re also going to revisit the notion of standardized preprocessor syntax. Unlike the previous attempt known as CoCo, what we want to do is standardize existing practice that resembles C preprocessing, with an aim to preserving compatibility, though we are finding interesting differences across the various implementations.
If you want to read the new standard, ISO will be happy to sell you a copy. The committee itself uses an “interpretation reference document”, standing document 007 on the J3 web site. At the time I post this, the latest 007 document 23-007r1 is close, but not quite the same as the published standard. There will eventually be a newer one, probably called 24-007.
It’s official – Fortran 202X has entered the “Committee Draft” phase in its development. This is one of the last few steps in the process of creating a new (or revised) ISO standard. To get here, all of the ISO National Bodies (INCITS PL22.3, informally “J3”, is the US National Body) had to agree that the draft was ready, but they also could (and some did) make comments that will have to be reviewed.
“GOD IS REAL, unless declared INTEGER.” That’s the only Fortran joke I know, the basis of which is one of the oldest (mis)features in the language, implicit typing. As it has been since The FORTRAN Automatic Coding System for the IBM 704 (1956), variables whose names start with the letters I through N are implicitly
INTEGER, all others are implicitly
REAL. (In ur-Fortran, these were called “fixed point” and “floating point”.) The earliest Fortran didn’t have type declarations at all, nor the
IMPLICIT statement. I think it safe to say that no other Fortran feature has caused programmers more trouble, yet it remains a “first-class” feature today. Some people want to change that, though the approaches vary. Let’s explore.
It’s right there in the (original) name – FORmula TRANslation. Formulas, or expressions, are an integral part of pretty much every Fortran program. The rules regarding evaluation of expressions in Fortran can sometimes be tricky, with some that will be surprising to those used to other languages.
Time for another “ripped from the headlines” post about a frequently misunderstood Fortran feature! Today I’m going to talk about non-decimal constants, often referred to as BOZ constants – Binary (base 2), Octal (base 8) and Hexadecimal (base 16). (Yes, I know Hexadecimal doesn’t start with Z, but what can you do?)
Fortran is a strongly typed language, meaning that entities (variables, etc.) have a type that is largely known at compile-time and can be checked by the compiler. In addition to the intrinsic types that existed in FORTRAN 77 (integer, real, complex, logical, character), Fortran 90 added the concept of user-defined types or “derived types”. (FORTRAN 66 and 77 considered
DOUBLE PRECISION its own type, which led to some weird carve-outs in the language that persist to this day.)
Former Fortran committee member Jerry Wagener sent this sad news today:
Walt Brainerd passed away on June 4th, 2020. He had cancer of the brain stem.
Walt joined X3J3 in the mid 1970s and was a strong advocate for Fortran for the rest of his life. He authored and co-authored many books on Fortran, taught classes, gave seminars, and ran “The Fortran Company” website.
On X3J3, Walt consistently advocated adding clear modern features and deprecating old, unsafe, features; often against strong opposition. He encouraged the numerical analysis community to take an interest in Fortran development and he was the typesetter for Fortran 90. Throughout all of the Fortran struggles and joys, he was just a good guy.
He was teaching a class at the end of February and had a fall. After he flew home and went to the hospital, they discovered a mass on his brain stem. He was in home hospice when he died. His family was with him.
I met Walt only once, at the “Fortran Geezers” meeting in 2017, but had many online interactions with him. Walt was a tireless supporter of the Fortran language and continued teaching Fortran classes after his retirement. If more details or an official obituary become available, I will update this post.
Yet another post ripped from the headlines of a user question, plus an earlier discussion in another Fortran-related group. The question at hand is: Does Fortran have any “reserved words”? These are identifiers that you must not use for your own variables, procedures, etc. The answer is…
I have often said that my least-favorite feature of the Fortran language is “OPEN on a connected unit”. In most cases, programmers invoke this accidentally and are confused by its behavior. But it does provide a way to do something useful for which the language doesn’t provide an alternative. Let’s explore.
In my Twitter feed today was this gem from user @science_dot:
There is very little proper Fortran 77 in the world. Legacy Fortran almost always uses extension from MIL-STD-1753 and we should call most legacy Fortran “Fortran 80” to reflect when those compiler features would have been broadly available.
I agree completely – nearly every bit of code I see someone call “FORTRAN 77” isn’t at all. Sure, there are the obvious things such as INTEGER*4 and STRUCTURE/RECORD that are extensions that never made it into any standard. But I’ll often see INCLUDE or END DO, which were also not part of FORTRAN 77; they were part of another standard, MIL-STD-1753.