Degenerate Conic

Algorithms • Modern Fortran Programming • Orbital Mechanics

Mar 27, 2022

The New Features of Fortran 202x

new-features-of-fortran2020x

The glacially slow pace of Fortran language development continues! From the smoke-filled room of the Fortran Standards Committee, the next Fortran standard is coming along. It has not yet been given an official name but is currently referred to as "Fortran 202x" (so hopefully we will see it before the end of this decade). Recall that Fortran 90 was originally referred to as "Fortran 198x".

A document (from John Reid) describing the new features is available here and is summarized below:

  • The limit on line length has been increased to ten thousand characters, and the limit on total statement length (with all continuation lines) has been increased to a million characters.
  • Allocatable-length character variables were added in Fortran 2003, but were ignored by all intrinsic procedures, until now! Better late than never, I suppose. In Fortran 202x, intrinsic routines that return strings can now be passed an allocatable string and it will be auto-allocated to the correct size. This is actually a pretty great addition, since it fixes an annoyance that we've had to live with for 20 years. Of course, what we really need is a real intrinsic string class. Maybe in 20 more years we can have that.
  • typeof and classof. No idea what these are for. Probably a half-baked generics feature? What we really need is a real generics feature. Since that is in work for Fortran 202y I don't know why these have been added now. Probably we will discover in 10 years that these aren't good for much, but will be stuck with them until the end of time (see parameterized derived types).
  • Conditional expressions. This adds the dreadful C-style (a ? b : c) conditional expression to Fortran. Somebody thought this was a good idea? This abomination can also be passed to an optional procedure argument, with a new .nil. construct to signify not present.
  • Improvements to the half-baked binary, octal, and hexadecimal constants.
  • Two string parsing routines (split and tokenize) were added. These are basically Fortran 90 style string routines that I guess are OK, but why bother? Or why limit to just these two? See above comment about adding a real string class.
  • Trig functions that accept input in degrees have been added (e.g. sind, cosd, etc). These are already commonly available as extensions in many compilers, so now they will just be standardized.
  • Half revolution trig function have also been added (acospi, asinpi, etc.). I have no idea what these are good for.
  • A selected_logical_kind function was added. This was a missing function that goes along with the selected_real_kind and selected_int_kind functions that were added in Fortran 2003. Logical type parameters (e.g., logical8, logical16, etc. were also added to the intrinsic iso_fortran_env module).
  • Some updates to the system_clock intrinsic.
  • Some new functions in the ieee_arithmetic module for conformance with the 2020 IEEE standard.
  • Update to the c_f_pointer intrinsic procedure to allow for specifying the lower bound.
  • New procedures were added to iso_c_binding for conversion between Fortran and C strings. This is nice, since everyone who ever used this feature had to write these themselves. So, now they will be built in.
  • A new AT format code, which is like A, but trims the trailing space from a string. Another nice little change that will save a lot of trim() functions.
  • Opening a file now includes a new option for setting the leading zeros in real numbers (print them or suppress them).
  • Public namelists can now include private variables. Sure, why not?
  • Some updates for coarrays (coarrays are the built-in MPI like component of Fortran).
  • A new simple procedure specification. A simple procedure is sort of a super pure procedure that doesn't reference any variables outside of the procedure. Presumably, this would allow some additional optimizations from the compiler.
  • A new "multiple subscript" array feature. The syntax for this is just dreadful (using the @ character in Fortran for the first time).
  • Integer arrays can now be used to specify the rank and bounds of an array. I tried to read the description of this, but don't get it. Maybe it's useful for something.
  • Can now specify the rank of a variable using an integer constant. This is nice, and makes the rank parts of the language a little more consistent with the other parts. Again, this is something that is cleaning up a half-baked feature from a previous standard.
  • Reduction specifier for do concurrent, which is putting more OpenMP-like control into the actual language (but just enough so people will still complain that is isn't enough).
  • enumeration types have been added for some reason. In addition, the half-baked Fortran 2003 enum has been extended so it can now be used to create a new type. I'm not entirely sure why we now have two different ways to do this.

fortran-committee

So, there you have it. There are some nice additions that current users of Fortran will appreciate. It will likely be years before compilers implement all of this though. Fortran 202x will be the 3rd minor update of Fortran since Fortran 2003 was released 20 years ago. Unfortunately, there really isn't much here that is going to convince anybody new to start using Fortran (or to switch from Python or Julia). What we need are major additions to bring Fortran up to speed where it has fallen behind (e.g., in such areas as generics, exception handling, and string manipulation). Or how about some radical upgrades like automatic differentiation or built-in units for variables?

References

Apr 26, 2020

New Blood

fortran_logo

It's been about 8 months since my screed about things that were wrong with the Fortran ecosystem and standards committee. I got a lot of feedback from that post. It seems like a lot of people felt the same way. The funny thing is, it seems like some things are slowing beginning to change:

  • A new GitHub repo was created for the community to work on proposals for the Fortran standard, to be discussed at committee meetings. This is unprecedented, and hopefully is just the beginning of putting the actual standard on GitHub for community inputs and editing.
  • A new project: the Fortran standard library has begun to be developed on GitHub. This is for things that have been left out of the standard, and can be added to a library much quicker than the standard and compilers can be updated.
  • A new website has appeared: fortran-lang.org as well as an associated project on GitHub. The goal of this is to be "the home" of Fortran on the internet. Something the two Fortran committee websites have never attempted to be. This site is community created (the contents are also on GitHub, so join us in helping to make it better).

These efforts are terrific, and serve as an online focus for the Fortran community, which up to this point has been mostly scattered and unorganized. The Fortran standards development process has hitherto been extremely opaque to the user community, so shining (still just a little bit of) light on that is good for everybody I think.

It has been clear for some time that some kind of change was needed in how the Fortran language is developed. In my view, the Fortran standards committee has failed spectacularity in the years since the release of Fortran 2003. Fortran 2003 was an amazing update to Fortran 95 that significantly expanded the utility of the language. Since then (for almost two decades) the focus has been on supercomputers and incremental improvements. The main pillar of Fortran language development seems to be to make absolutely sure that 50 year old spaghetti code still works without any modifications, even at the expense of correcting mistakes from decades ago that continually bedevil beginner Fortran programmers. In the meantime, Python (basically a scripting language used to wrap C/C++ libraries) has almost completely taken over scientific/technical computing, and amazing new languages have been created entirely from scratch (e.g., Chapel, Julia, Rust, Go, Swift) that all have made inroads into this field. All while the Fortran committee did very little to advance the language into new areas or make it more appealing to new programmers or people developing new libraries and codes. Fortran continues in some respects to hold its own on supercomputers and some massive legacy applications, but the writing is on the wall. The situation is dire, but I guess some of the committee seem to think nothing is wrong or they are in no hurry to do anything about Fortran's steady decline into irrelevance. According to a recent first-time attendee of the last committee meeting:

I spent last week at my first Fortran Standards Committee meeting. It was a pretty interesting experience. Everyone there was brilliant, and interested in trying to do a good job improving the language. And yet, it was still somehow very disfunctional.

everythingfunctional.wordpress.com

Recent Meeting of the Fortran Standards Committee. (I kid because I love!)

Recent Meeting of the Fortran Standards Committee. (I kid because I love!)

So I was very pleased to learn that Ondřej Čertík (@ondrejcertik) is running for chairman of the ISO Fortran Committee. Ondřej has been one of the main people spearheading all these new efforts. He also is the one behind LFortran, which looks to be one of the most innovative Fortran compilers in recent memory (actually moving Fortran just a little bit toward the direction of dynamic languages like Python, which is absolutely critical for getting new users onboard). Ondřej has published a platform which is fantastic. He has my total support (whatever that's worth!)

So, we'll see where all this goes. Hopefully things are improving. I encourage all Fortran users to support these new efforts, contribute to these new projects, and help with the website. Fortran is still a terrific language for numerical/scientific/technical computing. Getting the user community organized, improving the ecosystem, and improving the language standards process are only going to make it better in the long run.

Fun fact: the "F" Fortran logo shown above is based on the cover of the original IBM Fortran programmer's reference manual from 1956. Using the "WhatTheFont" feature at MyFonts.com, I determined that the font was Clarendon, or something very close to it. I created this icon in Inkscape some time ago in the original ugly brown color (e.g., it's the favicon for this website). Milan Curcic (@realmilancurcic) changed it to a nice purple and started using it on the fortran-lang.org website. I cleaned it up a bit and now SVG and PNG versions can be found here. I guess we'll use it until somebody comes up with something better.

See also

Aug 11, 2017

The New Features of Fortran 2015

FORTRAN2015

The glacially slow pace of Fortran language development continues! The next standard, Fortran 2015, mainly consists of updates for Fortran/C interoperability and new coarray features such as teams. In addition, there are a bunch of minor changes and discrepancy fixes. A few of the new features are:

  • The venerable implicit none statement has been updated to allow for some additional use related to external procedures.
  • The stop code in error stop can now be any integer or character expression.
  • An out_of_range intrinsic was added to allow for testing whether a real or integer value can be safely converted to a different real or integer type and kind.
  • You can now declare the kind of the loop variable inside an implied do loop. For example: iarray = [(2*i, integer :: i=1,n)].
  • All procedures are now recursive by default. This is an interesting change. Ever since recursion was added to the language in Fortran 90, a procedure has had to be explicitly declared as recursive. Now, you have to use non_recursive if you don't want to allow a procedure to be used recursively.
  • Some new syntax to indicate the locality status of variables within a do concurrent loop.
  • There are a lot of new IEEE intrinsic routines for some reason.

Fortran 2015 is expected to be published in 2018.

See also