From J.Reid@letterbox.rl.ac.uk Thu Mar 17 15:24:21 1994 Received: from ib.rl.ac.uk by dkuug.dk with SMTP id AA28943 (5.65c8/IDA-1.4.4j for ); Thu, 17 Mar 1994 16:24:49 +0100 Received: from letterbox.rl.ac.uk by ib.rl.ac.uk (IBM VM SMTP V2R1) with TCP; Thu, 17 Mar 94 15:24:53 GMT Received: from jkr.cc.rl.ac.uk by letterbox.rl.ac.uk with SMTP (PP) id <03771-0@letterbox.rl.ac.uk>; Thu, 17 Mar 1994 15:23:25 +0000 Received: by jkr.cc.rl.ac.uk (4.1/SMI-4.1) id AA04673; Thu, 17 Mar 94 15:24:21 GMT Date: Thu, 17 Mar 94 15:24:21 GMT From: jkr@letterbox.rl.ac.uk (John Reid) Message-Id: <9403171524.AA04673@jkr.cc.rl.ac.uk> To: SC22WG5@dkuug.dk Subject: Corrigendum 2 ballot, part 2 X-Charset: ASCII X-Char-Esc: 29 I have constructed a draft vote, which includes 7 noes. They fall into 2 categories: 1. In 2 cases, I think there is a technical problem. 2. In 5 cases, I think that edits are not needed in the corrigendum, though would probably be appropriate as part of the 95 revision. These are my category 2 noes. Comments, please. John Reid. Y|wc N N865 Item |_|_| |x| 000000b Minor edits and corrections to ISO/IEC 1539:1991 (E) I vote yes on items 1-3 and no on 4. Item 4 is a proper change for the 95 revision but is too trivial to include in a corrigendum. |_|_| |x| 000004 Blanks in format specifications in free source form This response introduces three edits to the standard when only one is needed. The third edit does it all. It is inappropriate to change the definition of 'keyword' in a corrigendum, though it may be a proper change for the 95 revision. Here is an alternative response. Note that this item is coupled to item 58, with which I also disagree. NUMBER: 000004 TITLE: Blanks in Format Specifications in Free Form Source KEYWORDS: free form source, format specification, blanks DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Is the following format specification valid in free form source? FORMAT (B N) ANSWER: Yes. Discussion: Sections of Fortran 90 are not consistent. 3.3.1: In free form, blank characters must not appear within lexical tokens other than in a character context. and A blank must be used to separate name, constants, or labels from adjacent keywords, names, constants, ... 10.1.1: Additional blank characters may appear at any point within the format specification, with no effect on the interpretation of the format specification, except within a character string edit descriptor." It can be seen that the text in chapter 3 does not consider edit descriptors. The text will be revised so that blanks are allowed in edit descriptors. REFERENCES: ISO/IEC 1539:1991 (E) sections 3.3.1, 10.1.1 EDIT(S): Section 3.3.1, second paragraph [22:6], change "... character context." to "... character context or in a format specification." |_|_| |x| 000058 Ambiguous use of "keyword" This response is quite out of proportion with the minor problem identified in the question (which is quite different from that in N808, question 2). All that is needed is a minor change to 3.2.1. Here is an alternative response. NUMBER: 000058 TITLE: Ambiguous use of "keyword" KEYWORDS: keyword, argument keyword DEFECT TYPE: Erratum STATUS: X3J3 draft response QUESTION: Is the use of "keyword" in 12.4.1 page 172 1st paragraph consistent with the definition of "keyword" in 3.2.1, page 19? Is the definition of keyword in 3.2.1 consistent with the two definitions of keyword in 2.5.2 page 16? In 13.10 page 188 is "keyword" the correct term (or should it be "argument keyword")? ANSWER: The term "keyword" is used for both "statement keyword" and "argument keyword", see 2.5.2 and Annex A. Which is intended is usually clear from the context, and this is so on pages 172 and 188. 3.2.1 is referring only to statement keywords and would be clearer if the qualifier "statement" is added. REFERENCES: ISO/IEC 1539:1991 (E) sections 2.5.2, 3.2.1, and Annex A. EDIT(S): Page 19, section 3.2.1 [19:37-38] Change "Keywords" to "Statement keywords", twice. rationale: 3.2.1 is not referring to argument keywords. |_|_| |x| 000097 Specification expression Edits in a corrigendum and have to be applied manually by the reader. Therefore wholesale rewrites of paragraphs should be avoided unless the need is absolutely overwhelming. These should be defered to the 95 revision. Is anyone being seriously misled by the present wording? |_|_| |x| 000155 Multiple USE statements, rename and only lists. Edits 1 to 3 are not necessary. There are many other places in the standard where the same interpretation can be reached by more than one path through the syntax. For example, boz-literal-constant could be removed from R533 since it is a special case of a scalar-constant. Edits 1 to 3 should be made in the construction of Fortran 95 but excluded from the corrigendum.