From LJM@SLACVM.BITNET Fri Dec 18 13:32:00 1992 Received: from vm.uni-c.dk by dkuug.dk with SMTP id AA09506 (5.65c8/IDA-1.4.4j for ); Sat, 19 Dec 1992 06:36:58 +0100 Message-Id: <199212190536.AA09506@dkuug.dk> Received: from vm.uni-c.dk by vm.uni-c.dk (IBM VM SMTP V2R2) with BSMTP id 4592; Sat, 19 Dec 92 06:38:30 DNT Received: from SLACVM.SLAC.STANFORD.EDU by vm.uni-c.dk (Mailer R2.07) with BSMTP id 7190; Sat, 19 Dec 92 06:38:29 DNT Received: by SLACVM (Mailer R2.08 R208004) id 5099; Fri, 18 Dec 92 21:36:30 PST Date: Fri, 18 Dec 1992 21:32 -0800 (PST) From: "Len Moss" To: "SC22/WG5 Mailing List" Subject: Draft Procedures For Requirements X-Charset: ASCII X-Char-Esc: 29 I had planned to circulate the following paper among the members of the JOD subgroup before submitting it to the next meeting. However, between Christmas shopping and a mainframe operating system upgrade I ran out of time (I'm off on vacation for a couple weeks after tonight). I'm going to submit it anyway so that we have something to shoot at when this comes up at the next meeting. It is, in any case, only a first draft and will probably have to be revised a number of times as we figure out what we are doing. My apologies to the JOD subgroup for not getting this out sooner, and happy holidays to all! [I decided to send this to the WG5 list instead of just the X3J3 list since WG5 may also want to think a bit about procedures for handling requirements.] - - - - - C u t h e r e - - - - - X3J3/93- To: X3J3 From: Len Moss Subject: Fortran Requirements Procedures Fortran Requirements Procedures The "Strategic Plan for Fortran Standardization" (WG5 Standing Document 4, also, X3J3/92-188) calls for a clear separation between the requirements and development functions in future Fortran standardization work and requires WG5 to maintain a database of "needs and suggested requirements for Fortran". The reorganization plan accepted at the November 1992 X3J3 meeting (X3J3/92-181) identifies document X3J3/9x-004 (also known as the Journal Of Development) as X3J3's input to this WG5 database. Proposals for Fortran Requirements to be included in /9x-004 will be processed as follows. 1. Proposals for Fortran Requirements, or FRs, should be approximately one to two pages long, and must contain the following sections: Title, Requirement, and Justification. The title should be less than a line long. The "Requirement" section should be a succinct but complete description of the functionality required; it should not include implementation considerations, such as proposed syntax. The "Justification" section should address questions such as: How does this requirement benefit users? Which users does it benefit? 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)? How does this requirement impact existing Fortran codes and implementations? Additional sections or subsections may be added by the proposer (e.g., "Summary of Requirement" if the requirement itself is lengthy, "Implementation Considerations", etc.). An example proposal is attached, which includes a possible SGML-like format and several optional sections. Proposals may be submitted in any reasonable format providing the required sections are clearly identified. The JOD subgroup will determine the internal format in which the JOD will be maintained. 2. A proposal for an FR should be submitted to a regular X3J3 pre-meeting distribution. If an appropriate technical subgroup exists, the proposal should be assigned to it for a recommendation on whether it merits additional X3J3 consideration; otherwise, the JOD subgroup will make this recommendation. The JOD subgroup will also review the proposal to insure that it is complete and follows the form outlined above. If necessary, the JOD subgroup will work with the author(s) and/or the technical subgroup to prepare a complete proposal for presentation to the full committee. 3. A proposal must be approved by a majority vote of X3J3 to be entered into the JOD. At this point it becomes a "proposed Fortran Requirement" or pFR and is assigned a permanent number and a status of "X3J3 consideration in progress". This initial full committee vote does not constitute approval of the requirement but merely indicates that the idea is a candidate for consideration during future revision cycles. While the pFR has the status "X3J3 consideration in progress" substantive changes may be made by a majority vote of X3J3 and editorial changes by the JOD subgroup. 4. A pFR may be submitted to WG5 by a two-thirds vote of X3J3. At this point, it becomes an FR and its status becomes "X3J3 approved; ready for WG5". Depending on the procedures WG5 adopts, this submission may be specific to a particular revision cycle, or may permanently add the requirement to WG5's requirements database. 5. A pFR or an FR may be withdrawn from active consideration by X3J3 by a two-thirds vote of X3J3. At this point its status becomes "Archival". 6. When an FR has been substantially satisfied by a new revision of the Fortran, or a related, standard its status may be changed to "Satisfied" by a two-thirds vote of X3J3. - - - - - A t t a c h m e n t - - - - - 42 Life, the Universe and Everything <KEYWORDS> intrinsic, meaning, life, universe, everything <STATUS> X3J3 consideration in progress <VERSION> 1 <REQUIREMENT> Add an intrinsic capability to calculate the meaning of life, the universe, and everything. <JUSTIFICATION> For millennia, users have had to struggle on their own to figure out the meaning of life, the universe, and everything. Many have never succeeded. Providing a facility to solve this problem as a standard part of every Fortran compiler would be of inestimable value, not only to the Fortran community itself, but to all humankind. <IMPLEMENTATION CONSIDERATIONS> A convenient implementation for users would be to provide this capability via a new function. However, it is quite likely that such a function would have side effects, so a subroutine interface might be preferable. In either case, it might be desirable to package the procedure inside a new intrinsic module (perhaps named TRANSCENDENTALS) rather than cluttering up the name space with yet another intrinsic procedure. <COMPATIBILITY CONSIDERATIONS> Aside from possible name clashes between the new intrinsic procedure or module and user-written code, this capability should not introduce any incompatibilities with existing standard-conforming source programs. The suggested procedure interface should help guarantee a smooth migration path for users with a large inventory of object code. <REFLIST> <REF> Torah; Moses. <REF> The Gospels; Matthew, et al. <REF> The Koran; Mohammed. <REF> the collected works of D. Adams. </REFLIST> <SUBMITTED BY> Len Moss <HISTORY> <EVENT> First proposal, X3J3/9x-042, submitted by L. Moss to meeting ???. <EVENT> X3J3/9x-042r2 accepted for consideration at meeting ??? (UC). </HISTORY> </FORTREQ> -- Leonard J. Moss <ljm@slac.stanford.edu> | My views don't necessarily Stanford Linear Accelerator Center, MS 97 | reflect those of SLAC, Stanford, CA 94309 | Stanford or the DOE