110 degrees in the shade, 9 Fortran geeks and dozens of comments and complaints about Fortran: it must be another J3 meeting in Las Vegas! J3 is the US Fortran Standards Technical Committee, a subcommittee of the International Committee for Information Technology Standards (INCITS). J3 works closely with the International Fortran Standards Committee (ISO/IEC/JTC1/SC22/WG5) and is responsible for developing the content of Fortran standards.
J3 meets four times a year; for a long time now, two of the meetings have been held in Las Vegas (inexpensive hotel rooms and good travel connections). The other two meetings are typically held alongside WG5 meetings, which float around the world. The Vegas meetings are generally in February (ok) and August (brutal!).
In the 1990s, J3 had as many as 40 members, with a mix of vendors and users (national labs, universities and user groups such as DECUS.) Due to consolidation, reduced budgets and other things, the membership of J3 is now down to 15 (eight voting members and seven alternates). Representatives from vendors on the committee include Cray, IBM, Intel, and Sun, with user representatives from JPL, LANL, George Mason University and others. HP had been a member but lost their status due to inactivity (they can rejoin after a while). Similarly, Fujitsu dropped out in the last year or so. NAG’s Malcolm Cohen is an alternate and does not usually attend the US meetings. Jim Xia from IBM usually attends, but was unable to make this one.
Intel’s voting member is Stan Whitlock, the Intel Fortran team lead. He used to be DEC’s and Compaq’s representative “back in the days”. Lorri Menard is our first alternate and I am second alternate. I had never been to a J3 meeting and asked Stan if I might accompany him to the August session. I wanted to meet the others, many of whom I knew only through email and newsgroup postings; the idea was that I would get a feel for how J3 did its business and perhaps help out with subcommittees.
Not a J3 member, but attending as an “observer”, was Toon (pronounced “tone”) Moene, a well-known gfortran developer from The Netherlands. Toon, like some of the other non-vendor members, pays his own way to attend. When I asked him about this, he commented that he “was single and didn’t have anything better to spend [his] money on.” I suggested that he needed to find a better-looking crowd to vacation with.
I was glad to meet Toon and chat with him about the unique aspects of open-source development. He commented that finding volunteers to work on the new and interesting features of the language was relatively easy, but that the drudge work of some of the darker corners was harder to fill.
I had already flown out to the area when Stan emailed me to say that he would not be able to attend, so I was on my own! Ulp! Thankfully, Committee chair Dan Nagle met me at the airport and introduced me to the others. He then put me right to work!
The major business of this meeting was to respond to the dozens of comments made during the recent public comment period for the draft Fortran 2008 standard. The comments were parceled out to subcommittees based on their topic: Data (declarations and such), HPC and interoperability, Interpretations, Edit (non-technical changes) and Journal of Requirements (JOR), which took everything else. Toon and I joined Dan on the JOR subcommittee.
I knew that some of the comments would have broad objections to establishing a new Fortran standard “so soon”, since there are not yet any complete implementations of the previous standard (IBM and Cray are probably closest.) I have a lot of sympathy for this position, but, as most of us agreed, it was much too late to do anything about it as the schedule and direction of F2008 was established years ago. F2008 could have been a “Corrections and Clarifications” revision, but there was a big push from user representatives to add major features, so that’s what happened.
A secondary topic that came up yet again at this meeting, as it has for the past couple of years, regarded the addition of “co-arrays” to the language. Co-Array Fortran (CAF) is a parallel programming addition which, unlike most others, is integrated into the language rather than a layer on top such as OpenMP or MPI. In some ways, CAF is similar in concept to Unified Parallel C in that the programmer view is of a single program that runs as parallel images with shared access to specific variables, “co-arrays”. In CAF, co-arrays look like regular arrays with an added dimension indexed using square bracket syntax. There are also a handful of synchronization calls.
It is true that the addition of co-arrays to the language has resulted in major edits to almost the entire language, but the editing has been done. There are several existing implementations of CAF, notably Cray’s, going back a decade. The objections come in two flavors: one is that a “better” parallel programming paradigm (PPP!) might come along later and Fortran would be “locked in” to CAF. This one makes no sense to me – if something better does come later, it can be adopted, but with the explosion of multi-core systems Fortran programmers need a standard and easy way of making use of parallel computation. Another objection is that some Fortran compilers have no parallel features at all, and even though one could implement CAF by recognizing the syntax but never running more than one image, users would “expect” parallel execution if they used the feature. The committee rejected both arguments and voted to keep co-arrays in the language. This issue will come up again at the next meeting, combined with WG5 in November.
Some of the comments objected to smaller features, such as the new (in F2008) ability to pass internal procedures as actual arguments. We’ve supported this for ten years, going back to DEC Fortran, but I’ll admit that the implementation can be tricky. The feature stayed in by a narrow vote margin. A couple of comments suggested that certain features were incomplete, such as the new G0 format for minimal-width output of any data type. The comment said that this needed an additional ability to specify a number of fraction digits, otherwise one might see Pi displayed as “3”. We agreed and I ended up writing the edit to add a G0.d form. (Hmm, writing that out reminds me of the old Fortran joke that “God is REAL – unless declared INTEGER.)
The Interop group worked on a request from the MPI Forum, which I was also involved with, to make it possible to declare a Fortran interface to a C routine that took “void *” arguments. Some compilers, including Intel’s, already have such a feature, but it’s typically implemented as a directive (ATTRIBUTES NO_ARG_CHECK in our case) which does fit the standard model.
After much wrangling, what we ended up with was two new features, assumed type and assumed rank. An assumed type argument is denoted by “TYPE(*)” and matches any type or kind of an actual argument. In generic resolution, it cannot be used to distinguish by type or kind. An assumed rank dummy argument matches any rank of an actual, including scalar. The syntax for this was the subject of extensive discussion: the obvious DIMENSION(*) is already taken for assumed size. What we ended up with was “DIMENSION(..)”: think of it as a colon on its side. A RANK intrinsic was also added to allow you to query the rank of the passed argument – a scalar is rank zero.
I, along with others, had argued that this feature was useful for writing Fortran routines, not just calling C. The problem is figuring out what the semantics are of accessing a variable of unknown type or rank. What we settled on was allowing you to pass an assumed-type or assumed-rank argument to C_LOC. You could then use C_F_POINTER to “cast” the variable to a pointer of a known type and rank. This feature gives you a way to implement, in a standard way, the old hack of a routine that copies arbitrary data by depending on the lack of interface checking. Note that these features are not being added to the Fortran 2008 draft itself, but rather to a “Technical Report” (TR) enhancing the C interoperability features. TRs are the way that features get defined in a common way with a promise that they will make it into the next revision of the standard with minimal changes. Allocatable components and function results were first done as a TR and were widely implemented before F2003 became standardized.
There’s a lot more that went on at the meeting – you can read the minutes and look at the various documents. Note that some documents underwent one or more revisions, denoted by “r1”, etc.
The next meeting, which is to be held alongside a WG5 meeting, will be in Tokyo in November. This is where the 2008 draft will be locked down and I expect one last attempt to strip CAF from the language. I will be there, representing Intel, and will be sure to let my readers know what happened. I’ve never been to Japan before and am looking forward to the experience (though not the plane ride getting there.)
Sayounara!
(Originally posted at Intel Developer Zone, copied with permission)