From JLS@liverpool.ac.uk Wed Nov 4 12:22:16 1992 Received: from vm.uni-c.dk by dkuug.dk with SMTP id AA20929 (5.65c8/IDA-1.4.4j for ); Wed, 4 Nov 1992 15:22:17 +0100 Message-Id: <199211041422.AA20929@dkuug.dk> Received: from vm.uni-c.dk by vm.uni-c.dk (IBM VM SMTP V2R2) with BSMTP id 1478; Wed, 04 Nov 92 15:23:42 DNT Received: from UKACRL.BITNET by vm.uni-c.dk (Mailer R2.07) with BSMTP id 2575; Wed, 04 Nov 92 15:23:41 DNT Received: from RL.IB by UKACRL.BITNET (Mailer R2.07) with BSMTP id 4020; Wed, 04 Nov 92 14:23:55 GMT Received: from RL.IB by UK.AC.RL.IB (Mailer R2.07) with BSMTP id 5727; Wed, 04 Nov 92 14:23:53 GMT Via: UK.AC.LIV.IBM; 4 NOV 92 14:23:00 GMT Received: from UK.AC.LIVERPOOL by MAILER(4.4.t); 4 Nov 1992 13:30:45 GMT To: SC22/WG5 members Date: Wed, 04 Nov 92 12:22:16 GMT From: Lawrie Schonfelder Subject: Re: S20/58 In-Reply-To: Your message of Tue, 3 Nov 92 15:47:13 GMT X-Charset: ASCII X-Char-Esc: 29 On Tue, 3 Nov 92 15:47:13 GMT jkr@UK.AC.RUTHERFORD.DIRECTORY said: >It seems to me that the response to S20/4 is introducing three edits to >the standard when only one is needed. The third edit does it all. There >is no need to mess around with the definition of 'keyword'. Here is an >alternative draft response. > >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 format >specifications. 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 p22 2nd pp [22:6] > change "... character context." > to "... character context or in a format specification." > >SUBMITTED BY: J.T. Martin 119-JTM-2 (119.015) > >HISTORY: X3J3/92-145 Draft Interpretation by CIO, withdrawn > X3J3/92-075 > X3J3/92-044 S20.120, number 4 > 119-RPK-1 > 119-JTM-2 > Approved as X3J3/92-176 at meeting 122 by unanimous consent > > I am only now getting time to look at my ballot on issues such as this and I am sorry to say that I think this is the wrong way to resolve this admitted confusion. Allowing B N in a format in free-form is like allowing INT GER in the keyword. I think an error was made in not properly extending the blank significance rules into the multicharacter edit descripters I will almost certainly vote no on this one, either in its original or in John's changed form, unless someone can convince me otherwise. Lawrie