From owner-sc22wg5 Wed Aug 7 18:47:08 2002 Received: from mail500.nifty.com (mail500.nifty.com [202.248.37.208]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id SAA89518 for ; Wed, 7 Aug 2002 18:47:07 +0200 (CEST) (envelope-from takata@edogawa-u.ac.jp) Received: from takata-n6 by mail500.nifty.com (8.12.4/3.7W-02/25/02) with SMTP id g77GkZV9025623 for ; Thu, 8 Aug 2002 01:46:36 +0900 Message-Id: <200208071646.g77GkZV9025623@mail500.nifty.com> X-Sender: takata@edogawa-u.ac.jp X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5-J (32) Date: Thu, 08 Aug 2002 01:46:34 +0900 To: sc22wg5@dkuug.dk From: TAKATA Masayuki Subject: Edits related to Japan's Interpretation Requests In-Reply-To: <200208051140.BAH32817.LUO@jp.fujitsu.com> References: < <11E691503E0C5440938B8A885016D8CB03AB1D86@AA02S1SV9.nthq01.unisys.co.jp> <11E691503E0C5440938B8A885016D8CB03AB1D86@AA02S1SV9.nthq01.unisys.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-2022-JP" Dear J3: Could you give this a J3 number for the coming joint meeting in Las Vegas? My apologies for the late submission. Regards, Makki ======================== cut here ======================================== From: Takata, Masayuki To: INCITS/J3 Subject: Edits related to Japan's Interpretation Requests Background: J3 discussed Fortran 95 Interpretation Requests from Japan, at its meeting #150, and classified the requests into four groups: "Fortran 95 Interpretation" - JOR subgroup will submit this item as a formal interpretation. "Recommended for Fortran 2000" - These items are problems, but they are not serious enough to warrant a formal Fortran 95 Interpretation. "Deferred to Editor" - J3 recommends that the editor of Fortran 2000 include these changes into the text of the Fortran 2000 draft. "Not Recommended" - J3 believes that no action is required on these items. Here are a list of edits for those items in the second and third classes above that are, I believe, not yet addressed properly in the current draft. References: J3/99-208 Interpretation requests of Japan (Takata) J3/99-221r1 J3 responses to interpretation requests from Japan (Dedo) ========================================== Part 1: Items recommended for Fortran 2000 ========================================== JP-1) [20:20] Insert "assignments" after "procedures,". JP-5) [66:5-7] Make the second sentence of this paragraph a new constraint C488 (to R464) and move it to [65:24+]. NOTE: JP-5 is classified as a Fortran 95 Interpretation, and the approved response to it suggests that the proposed edit take place in Fortran 2000, not in Fortran 95. That's because I include it here. See below. JP-13) [89:32] Change "DO variables of the containing data-implied-dos" to "DO variables of this data-implied-do and the containing data-implied-dos". JP-15) [90:22] Change "list" to "expanded sequence". JP-30) [217:38] Change "input/output statement" to "input statement". JP-34) [240:6-8] Rewrite the paragraph to read: "The processor may begin new records as necessary, but the end of record shall not occur within a constant except for complex constants and character sequences. The processor shall not insert blanks within a constant or character sequence." Check NAMELIST output in section 10.10.2. JP-42) [408:27] Delete "with a value that is not a statement label". ================================ Part 2: Items deferred to Editor ================================ JP-19) [126:5-6] Change "As the" to "The" twice. JP-25) [168:25] Delete "it specifies". JP-41) [274:30] Change "procedure" to "procedure name". JP-45) [430:31] Change "exponent range" to "range". JP-48) [477:26] Change "FLIP" to "FLIPS". ---------------------------------------------------------------------- FYI: excerpt from WG5 N1473 NUMBER: JP-05 TITLE: Construction of array values KEYWORDS: constructor DEFECT TYPE: Interpretation STATUS: Included in corrigendum/complete QUESTION: JP-5) 4.5 Construction of array values, "The ac-do-variable of an ac-implied-do that is in another ac-implied-do shall not appear as the ac-do-variable of the containing ac-implied-do." This sentence should be a Constraint. ANSWER: No. The requirement should be made a constraint in the next standard. It should remain a simple requirement in Fortran 95 to avoid invalidating existing implementations. EDITS: None SUBMITTED BY: Japan HISTORY: 99-208 Submitted 99-221 Classed as Fortran 95 Interpretation. WG5-N1411 Draft answer 00-260 m154 Passed by J3 meeting 00-329 m155 Failed J3 letter ballot WG5-N1463 Accept Henry's and Jon's comments 01-303r1 m158 Passed by J3 meeting 01-380 m158 Passed by J3 letter ballot WG5/N1470 Passed by WG5 ballot ---------------------------------------------------------------------- -- 江戸川大学 社会学部 人間社会学科　助教授　高田正之 〒270-0198　千葉県流山市駒木 474 tel: 04-7152-0661 ext.546 fax: 04-7154-2490 email: takata@edogawa-u.ac.jp