How to Propose a Fortran Requirement Len Moss, X3J3 Requirements Chair Now that Fortran 90 is an official standard, the Fortran standards committees have begun looking ahead. The future evolution of the language will be managed by an international subcommittee, ISO/IEC JTC1/SC22/WG5, usually known as WG5, with the technical work being done by X3J3, the US member body of WG5. A revision of the language scheduled for 1995 will be primarily devoted to clarifications, corrections and interpretations of Fortran 90, while a more substantial revision is planned for 2000. WG5 has established an ongoing process for collecting requirements for future Fortran revisions, and will make the final selection of requirements to be addressed by any particular revision. The various national committees, including X3J3, have been asked to solicit proposals for requirements from within their communities as input to WG5. Both X3J3 and WG5 want to make this process as open as possible and welcome proposals for requirements from any individual or group. On the other hand, most of us who serve on these committees do so on a largely volunteer basis and have only limited time and resources to devote to this effort. To make the process as efficient as possible, and thus to insure that all contributions can receive thoughtful consideration by the committee members, X3J3 has established the following procedures for handling proposed Fortran Requirements, or pFRs, within the US. WHAT'S A pFR? A pFR is a short document proposing a change to the Fortran standard. It can take a variety of forms, as long as it adheres to the following simple rules. DESCRIBE THE PROBLEM, NOT JUST THE SOLUTION. People who work with programming languages (the members of X3J3 and WG5 included) tend to be "problem solvers": when they encounter a problem they immediately start thinking of possible solutions. This approach is fine, but if your pFR does not clearly identify the shortcomings of the current standard which your solution is meant to address, it becomes very difficult to evaluate alternative solutions to the same (or similar) problems. RULE: A pFR must include a "Requirement" section, containing a clear and concise statement of the problem to be solved. It may be useful to think of a requirement as a set of criteria against which to judge a variety of possible solutions to your problem. (Incidentally, the word "requirement" in this context is not intended to imply any commitment to solve a particular problem, but only a clear statement of what would be required to solve it.) EXPLAIN WHY THIS PROBLEM SHOULD BE SOLVED. The Fortran community is extremely large and diverse, and all of us have opinions as to how our language could be "improved". Even after weeding out those with serious flaws, the remaining list of useful and implementable requirements is likely to be far too large to seriously consider adding to the language. Thus you need to explain why it's more important to spend limited resources on this requirement rather than on something else. RULE: A pFR must include a "Justification" section. Here are a few questions to think about when writing this section; you don't have to answer all of them, and you may think of some others. How does this requirement benefit users? Which users does it benefit? Why can't this requirement be satisfied by features already present in Fortran? Why should this requirement be addressed by a Fortran-related standard rather than by individual Fortran implementers or by a standard at some other level (e.g., an operating system standard)? What are the implementation costs of satisfying this requirement? How does this requirement impact existing Fortran codes and processors? BE BRIEF. Each member of a Fortran standards committee receives and processes a huge volume of information: the papers associated with a typical meeting total between 500 and 1000 pages, and there are usually at least four X3J3 and one WG5 meetings per year. A comparable volume of email is also exchanged between meetings. Given this environment, it is important to make your pFR as clear and concise as possible; a well-written half-page executive summary can be far more effective than a 100 page tome. RULE: The Requirement and Justification sections of a pFR must be no more than about two pages long, and must occur within the first two pages. If additional material is truly necessary, please incorporate it in separate, appropriately headed sections (e.g., "Background", "Possible Solution", etc.). If the requirement is complex and requires a lengthy explanation, consider dividing it into several independent requirements, or putting it in a section named something like "Detailed Requirement", and simply putting a summary in the "Requirement" section. A very long requirement section may in fact be a specification of a possible solution rather than a statement of the problem. Here are some additional suggestions for writing an effective pFR: o Give your pFR a brief but descriptive title. A good title can help immensely in thinking and talking about a proposal. o Get someone to criticize your pFR before you submit it, both for clarity and content. This will help you to anticipate and refute possible objections to your proposal (you might even decide not to submit it after all). o Include your name, phone number and address (email or postal) in the body of your pFR (envelopes and email headers often get lost or mangled). An example of a pFR is included below, along with a minimal template. The precise format is not important, however, as long as it satisfies the above rules. WHERE DO I SEND IT? If at all possible, please send your pFR as plain text email to: ljm@slac.stanford.edu (Internet) LJM AT SLACVM (BITNET) If this is not possible, try to send a plain text file on a Macintosh floppy disk to: Len Moss SLAC MS 97 P. O. Box 4349 Stanford, CA 94309 (phone: 415-926-3370) I will do my best to handle proprietary word processor formats and other electronic media, but I cannot make any promises. As a last resort, you can send your pFR as a paper document to the above address. In this case, however, anything over two pages cannot be accepted. Please make it clear that you are officially submitting a pFR. This is especially important if you submit your pFR via email, since all of us on the Fortran committees get a lot of casual inquiries and suggestions. A good way to alert me that this is an official submission is to include a subject line beginning with the string "pFR:". WHAT HAPPENS NEXT? When I receive your pFR, I will assign it a number and register it as part of X3J3's standing requirements document, X3J3/9x-004. I will also send you an acknowledgment, including the assigned pFR number. At the next X3J3 meeting, your pFR will be assigned to a subgroup for review. Unfortunately, we do not have the resources to keep you personally informed of the subsequent fate of your proposal. However, you may follow its progress yourself in the minutes of our meetings. To become an observer and automatically receive copies of X3J3's minutes and meeting announcements, write to: X3J3 Secretariat, CBEMA 1250 Eye Street NW, Suite 200 Washington, DC 20025 There is a yearly fee of approximately $300 for observers. If you have ftp access to the Internet, a number of X3J3 documents, including meeting minutes and the requirements document, can be obtained via anonymous ftp from the "/x3j3" directory at ftp.ncsa.uiuc.edu. This directory can also be accessed via an email archive server. To find out how to use it, send email to archive-server@ncsa.uiuc.edu with the command "help" on a single line in the body of the message. You must have a domain-style return email path (e.g., name@site.bitnet, name@site.edu, name@site.UUCP). If this email path cannot be readily deduced from the header of your email, include the command "path " on a separate line in the body of the message. For information about becoming a member of X3J3, please call or write the committee chair: Jerrold L. Wagener Amoco Production Research P. O. Box 3385 Tulsa, OK 74102 (phone: 918-660-3978) (email: jwagener@amoco.com) -------------------------------------------------------------------- EXAMPLE TITLE: Controlling Pointer Bounds SUBMITTED BY: Jeanne Martin (phone: ...; email: ... ) REFERENCES: ISO/IEC JTC1/SC22/WG5-N780 REQUIREMENT: Allow a user to specify the bounds of a pointer that is associated with a target by the pointer assignment statement. JUSTIFICATION: Currently a pointer that is associated with a target by the pointer assignment statement has the bounds of the target unless the target is an array section or an array expression, in which case the lower bound is one and the upper bound is the extent. The user has no control over setting the bounds. This is inconsistent with the passing of an actual argument array, array section, or array expression to a dummy argument. The lower bound of a dummy argument may be specified in a declaration statement. A user should have a similar amount of control over the bounds of array pointers. ESTIMATED IMPACT: This affects only the pointer facility. It will not invalidate any existing programs. -------------------------------------------------------------------- TEMPLATE TITLE: SUBMITTED BY: REQUIREMENT: JUSTIFICATION: ====================================================================