Welcome to the new home of the Doctor Fortran blog! Given that I have been retired from Intel for more than three years, it seemed appropriate to give my posts their own home on my web site. With Intel’s permission, I have copied here the posts I wrote while I was an employee. (Apparently four of those posts had been deleted – I was able to recover one of them.)
It’s also coming up on three years since John Reid asked me to step into his role as Convenor of the international Fortran standards committee WG5. A lot has happened since then and I thought I’d take the opportunity to recap what we’ve done and what we hope to do in the future.
I joined the standards effort back in 2008, just as Fortran 2008 was being finished (it wasn’t published until 2010.) Development of the next standard, initially (and optimistically) called Fortran 2015 but published as Fortran 2018, took a lot longer than anyone wanted. Along with others on the committee, I felt that a significant contribution to the delay was “feature creep” – we kept adding new features to the work list and spent a lot of time rehashing why some feature should or should not be included, to the detriment of getting the new standard done on time.
At the 2017 WG5 meeting in Garching, Germany, John, who was approaching 80, announced that he was retiring from the Convenor role and that I had agreed to take over. This was all subject to a formal country vote that happened later that year, but at the time there were no other candidates and everyone seemed fairly happy for me to step up. John invited me to address the group and present my vision for the road ahead.
A major issue at the time was that in 2017, seven years after Fortran 2008 was published, there was only one full-language Fortran 2008 compiler (Cray). Worse, many of the compilers in use at the time weren’t even full Fortran 2003! (The situation has improved quite a bit since then.) Programmers who wanted to use some of the newer features were often prevented from doing so due to their management requiring that a minimum of three (or even four) compilers support a given feature before it could be taken advantage of in their code. There was a widespread sentiment that the standard had moved too far ahead of the compilers and that the standard needed to “take a breather” and allow compilers to catch up. It didn’t help that this was a time of retrenchment among compiler developers, with some dropping out of the market entirely and others dealing with resource constraints.
I had two main goals in mind for the next revision after Fortran 2018, which we later started referring to as Fortran 202X (a temporary name – see here). The first was to limit the scope to “no more than two or three medium or large features” and to decide on a work list and then get that done. I said I wanted the next revision to be published in 2022 or 2023 at the latest. The second is that I wanted much more involvement from the user community than the committee had received in the past (partly due to the high fees the parent organization charged for participation.)
Over the years of my being on the standards committee I often found widespread misunderstanding of how we developed the standard, so I took it upon myself, in blog, forum and newsgroup posts, to explain the process and shed some light on “how the sausage gets made”. I had seen a growing frustration among users that they didn’t feel that the committee was working for them, and in some sense they were right. Nearly all of the changes and new features were proposed directly by existing committee members, who came from large government labs and compiler vendors. Notable by their absence was representation from commercial manufacturers (and this prompted me to recruit industry users to the committee, one of whom is now one of my alternates.)
What I proposed at the time, and then implemented, was a public and open-ended survey of the user community. I ran this for six months in 2017-2018, asking people to rank selected features we had seen requests for, to tell us about how they use the language, and to propose ideas for what they would like to see. In the end we received 137 responses and I tabulated these into WG5 document N2147. At the 2018 meeting in Berkeley, California, I asked each attendee to select five ideas either from the survey or their own thoughts. We correlated those and the various committee subgroups discussed and ranked them, assigning a difficulty/complexity level to each. WG5 as a whole then developed a preliminary work list from the items selected.
At the 2019 meeting in Tokyo, Japan, there was extensive discussion about two of the “large” items: generics and exceptions. Most everyone agreed that Fortran needed to do something more about generic programming than the language already had, but there was no consensus as to the approach. What we did was to take generics off the list for 202X but to immediately start work to make sure we had a proposal ready for the following revision, dubbed 202Y. A new Generics subgroup was formed, with Tom Clune of NASA as its head, to get things moving. Exceptions were more controversial, with wildly varying use cases and a serious concern that simply having exceptions in the language would necessarily slow down existing programs not using exceptions. That too was taken off the list, but discussion continues.
It was at the Tokyo meeting that I declared the work list “closed” (as I had been explaining for the past two years would happen), and this had widespread support. In the meantime, the US committee (officially PL22.3 but we all call it by the old ANSI name of J3) had been hard at work writing papers with specifications, syntax and edits for a majority of the work list items. The result is that 202X is very close to being done, with only a handful of features left to develop. We might even finish the “technical work” in 2021, which would allow for publication in 2022. Unfortunately, COVID-19 is getting in the way, causing us to shift the scheduled June 2020 WG5 meeting onto what would have been just a J3 meeting in October 2020. As I write this in April 2020, it’s unclear if the world will be in a state where even that can happen, but that’s the plan right now.
Another problem I noticed was the inefficient and manual way that J3 submitted and tracked proposals. There were two servers, uploading a paper didn’t always get associated with both a year and a meeting, use of an SFTP client was required, and tracking the status of papers was done manually by the J3 chair. I created a new j3-fortran.org web site (the old site was hosted at the University of Colorado) that was database-driven and provided better tools for uploading, downloading and tracking documents, all done within a web browser. I also created a new site for WG5, wg5-fortran.org, which took over from an anonymous FTP server hosted by NAG and that was manually updated. I pay for hosting and maintaining these, as well as the three J3 email lists. The J3 site, in particular, has made the processing of papers much easier and the committee all seems to love it.
In the last year a number of new members joined the committee, which I am delighted with – it seemed for a while we were shrinking. Better, these new members tended to be younger and were full of enthusiasm for the language. Several of the newer members created a Github Proposals Repository where ideas for the standard could be discussed. I was very much in favor of this and have been active in the discussions there. I expressed the hope that we could use the repository to develop ideas for Fortran 202Y (and beyond) so that when the work on a future revision starts we’d have ideas ready to work from. Ideally, papers would be developed between meetings. That hasn’t happened yet, but it could in the future.
My first three-year term as Convenor is drawing to a close, and I’m happy to serve another term. As it happens, one of the new members I spoke of earlier, Ondřej Čertík, has decided to also run for Convenor. Ondřej and I share many goals for the standard, including increased participation from the community and a faster cadence to revisions. Ondřej feels strongly that further improvements in the way J3 meetings are run are possible and should be pursued – I agree. While developing multiple open-source compilers, (one of Ondřej’s stated goals), is not something the WG5 Convenor can influence, it certainly would be great for the language if that happens. What the Convenor can do, and I have been working on, is making WG5 as a whole more inclusive and to remove obstacles that hurt the process and make contributors feel excluded.
In other news, I have been invited to be the keynote speaker at FortranCon2020, to be held at the University of Zurich, in July. This might need to be held virtually, but I am looking forward to it regardless.
There’s a lot to look forward to in Fortran, and I think the committee as a whole has become more focused and efficient in the past three years. The next three should be even more productive and I hope to be a part of that.
Comments