J3/06-179 To: J3 From: Dan Nagle Subject: Reply to DARPA (Project of Drs. Leuke & Gordon) Date: 8 May 2006 J3 is pleased that Drs. Leuke and Gordon were able to present the concerns of DARPA to us, and to understand those concerns and to discuss the issues involved. It is difficult from the point of view of a standards technical committee to address all these concerns within the confines of a language specification for a number of reasons. We address these reasons in the following. In short, a language standard specifies the means for writing a correct program, and the effects of executing a correct program. It cannot easily describe the effects of arbitrary occurrences within an incorrect program. The Fortran standard has features which promote the detection of common programming errors. These features include explicit interfaces to subprograms (for detection during compilation of argument list mismatches), the implicit none statement (to detect misspelled or incorrectly declared names), provision for return status values for input/output statements and memory allocation statements (to provide an indication of the success or failure of the request), and the strict rules for arrays of different ranks (which may be enforced during compilation) and array extent bounds (which are usually enforced optionally during execution) which promote detecting array addressing errors. How well a particular compiler documents its usage and makes available indications of errors is beyond the standard's means to specify. These factors are what is described as "Quality of Implementation" issues. Along with the size and complexity of a program that will cause any particular compiler to fail, these issues are not now specified by the standard, and they could be specified by the standard only with great difficulty. Thus, indications of errors encountered during compilation or during execution are vendor specific. Language design involves a number of tradeoffs, including a tradeoff by the standard between ease of application debugging versus application execution efficiency. The marketplace for compilers is the best arbitrator of the balance between these competing goals. Different compiler vendors have chosen to emphasize different aspects of compilers in their respective products. Some have placed the emphasis on execution efficiency, others have selected error detection; some vendors have selected support for legacy programs, others have placed correct compilation according to the latest revision of the standard as the more important goal. Thus, use of a variety of compilers often catches more problems than use of any one compiler. J3 feels that the use of coding standards to require the best use of available features of any programming language is a necessary ingredient when attempting to reduce the overall effort needed to make and use application software. Failing to use features already present in a language weakens the case that new features are needed. Use of straightforward coding constructs and avoidance of constructs where the intention is provided by subtle effects (and therefore errors are made difficult to detect) is a part of the programming discipline. A further issue arises in the decision of whether to detect an error during execution, or to detect the error during compilation. Fortran has attempted to provide features which assist the detection of errors during compilation. J3 believes this early detection of errors provides more efficient use of the application programmer's time than detection of errors during execution. Furthermore, it allows the detection of other errors as well, and it eases the diagnosis of other errors caught during execution. Examination of status values returned from allocation and input/output statements, for example, may lead to an incorrect value having been passed to the request thereby causing the failure. This is analogous, in the C programming language, to checking function return values or the error variable errno when requests are made. The standard's interface to the IEEE floating point arithmetic abilities of the underlying hardware are another example of where the application programmer can control the application program's behavior to report the occurrence of errors. Many vendors provide compilers to support more than one programming language, yet use a common code generator and run-time libraries to provide the actual hardware instruction sequences. Many times, this imposes conflicting demands on library writers, as different languages require different behavior in the face of invalid operations. Thus, a vendor may not respond to a programming error as any one particular language demands, due to the requirements of another language. J3 is pleased to have heard the concerns expressed to it. However, the issues raised are more difficult to resolve than might be imagined. J3 will keep these concerns in mind when developing future revisions of the Fortran standard. However, too much effort is required to fully comply with the specific requests made for the revision of the Fortran standard scheduled to be finalized during 2008.