In this blog, I refer to myself as “Doctor Fortran”.  It’s a joke that started more than ten years ago when I decided to write an “advice column” for what was then the Digital Visual Fortran Newsletter.  Everyone liked it so much I stuck with it, but I’ve always been aware of the people who deserve that title far more than I – the members of the Fortran standards committee.  As it happens, I am an “alternate” member of the committee representing Intel, but most of the time we are represented by Stan Whitlock.  Intel Fortran developer Lorri Menard is our other alternate member.  I’ve now attended three standards meetings and thought I’d write up my experience of the most recent and give readers a feel for how the Fortran language’s evolution is guided and its cohesiveness maintained. First, some background.  There is the International Standards Organization (ISO) Fortran committee whose full designation is ISO/IEC/JTC1/SC22/WG5 .  We’ll call that WG5 for short. WG5 has members from around the world – its charter is to establish the direction for the Fortran standard: at a high level, which features should it have?  WG5 also has the final approval on a new standard, with each member country having one vote. WG5 meets once a year at a location that shifts among various member host countries. WG5 doesn’t do the nuts-and-bolts work of developing the standard – that task is assigned to the US Fortran standards committee, a subset of WG5.  Formally called INCITS PL22.3, members typically refer to it as J3 , a term dating back to the American National Standards Institute (ANSI) X3J3 committee. J3 has representatives from vendors (Cray, IBM, Intel, NAG, Oracle) and users (universities, national labs and individuals.)  The J3 meetings, held three times a year, are also regularly attended by voting alternates from inside and outside the US, including Toon Moene of the gfortran project. One of the three yearly J3 meetings is held coincident with the yearly WG5 meeting. It was my honor to be Intel’s representative at the June 2011 joint WG5/J3 meeting, held in Garching, Germany, a pleasant suburb of Munich, at the LRZ Supercomputing Center (LRZ stands for Leibniz-Rechenzentrum or Leibniz Research Center.)  The Fortran 2008 standard had been approved the previous October, so you might think we didn’t have much to do, but the week was full. No, we were not starting to design the features for the next Fortran standard – in fact, it was generally agreed that wouldn’t happen for another year or two, and WG5 still needed to come up with the general direction for the next standard.  Many members of J3 and WG5, including myself, are of the opinion that the next standard should be a “corrections and clarifications” version with few or no new features so that vendors and users have a chance to “catch up”. The biggest work item was TS 29113 on Enhanced C Interoperability. In standards speak, TS means Technical Specification and in this case is used when there is a language feature whose design is not complete in time for standards approval but is firm enough to encourage vendors to implement it.  (In the past, this was called TR for Technical Report.)  Typically, when a TS has been approved it is agreed that it will be incorporated in the next standard as-is, minimizing risk to vendors and users. The most well-known use of a TS in the past was the one that brought us allocatable components of derived types, incorporated into Fortran 2003. TS 29113, or “the Interop TS”, wants to extend the C interoperability features of Fortran in two main ways: Allow C procedures to be passed assumed-shape, pointer and allocatable variables and to give C programmers the means to read, write, and reallocate such arguments, and also to allow C to define such variables and pass them to Fortran Provide support for interoperability with a C “void *” argument that has no explicit type or shape The TS underwent significant changes during the week, but the fundamental ideas remained: The concept of “assumed type”, designated by TYPE(*), and “assumed rank”, designated by DIMENSION(..).  Think of the .. as a colon on its side – DIMENSION(*) already has a meaning in Fortran The notion of a “C descriptor” with a known structure, and a C header file that declares the structure and functions C code can call to manipulate these descriptors. For more details on the Interop TS, you can read the current TS 29113 draft (PDF). The other major task that occupied us was interpretations.  These are submitted by users and vendors when they think there is an ambiguity in the standard or they want to know if a particular meaning was intended by the committee.  There was quite a backlog of these, as development of F2008 had taken up a lot of time, but we knocked off a lot of them. I remember one I worked on which asked if parameterized derived types could have the SEQUENCE attribute, as if they could, this greatly complicated the process of determining when two derived type declarations were “the same”.  (We concluded that it made no sense to allow parameterized derived types to be SEQUENCE types.)  Another interpretation lifted the restriction that the arguments to C_LOC and C_F_POINTER be interoperable, greatly increasing their usability. The process works this way.  One or more members takes an interpretation request and, if necessary, rewrites it to refer to the current standard, since many were submitted against Fortran 2003.  An answer is proposed – it may be that the standard is correct as-is and no change is required, or a wording change is proposed.  The answer is then voted on by the members present.  Sometimes there are objections and another revision is made.  If the interpretation is approved, it then goes on a letter ballot submitted to all J3 members, who can approve, approve with comments, or reject (with comments).  Lastly, a ballot of WG5 members is done. Only if the interpretation passes this third round is it considered part of the standard, and later included in a set of edits called a corrigendum. As a break from working on the standard, we got a tour of LRZ’s immense building housing its multiple supercomputer clusters.  Photographs were not allowed in here, but I was impressed by the extensive and elaborate lightning and fire suppression systems.  Later in the week we also got a tour of the Munich Computer Museum, with working examples of many significant computers from the past.  You can view a gallery of the photos I took here .  And then there was the atrium of the LRZ building where we ate lunch.  It features two giant tube slides that go from the fourth floor down to the first.  Blankets were provided if you wanted to try it out, but I didn’t see anyone do so while I was there. Each time I have attended a standards meeting, I have been impressed with the members’ dedication to the Fortran language.  While there are a variety of personalities on the committee, they all work together to make Fortran the best it can be.  I’m glad to have been a small part of this effort and look forward to future opportunities to participate in Fortran’s future.