From robert.corbett@eng.sun.com Thu Feb 8 07:56:56 2001 Received: from mercury.Sun.COM (mercury.Sun.COM [192.9.25.1]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id HAA33101 for ; Thu, 8 Feb 2001 07:56:55 +0100 (CET) (envelope-from robert.corbett@eng.sun.com) Received: from engmail4.Eng.Sun.COM ([129.144.134.6]) by mercury.Sun.COM (8.9.3+Sun/8.9.3) with ESMTP id WAA06574; Wed, 7 Feb 2001 22:56:34 -0800 (PST) Received: from phys-mpkmaila (phys-mpkmaila.Eng.Sun.COM [129.146.1.131]) by engmail4.Eng.Sun.COM (8.9.3+Sun/8.9.3/ENSMAIL,v2.1p1) with ESMTP id WAA11346; Wed, 7 Feb 2001 22:56:33 -0800 (PST) Received: from conversion-daemon.mpkmail.eng.sun.com by mpkmail.eng.sun.com (iPlanet Messaging Server 5.0 Patch 1 (built Nov 9 2000)) id <0G8F00F01E2DIA@mpkmail.eng.sun.com>; Wed, 07 Feb 2001 22:56:19 -0800 (PST) Received: from lupa (lupa.Eng.Sun.COM [129.146.78.104]) by mpkmail.eng.sun.com (iPlanet Messaging Server 5.0 Patch 1 (built Nov 9 2000)) with SMTP id <0G8F00DF9F9U4N@mpkmail.eng.sun.com>; Wed, 07 Feb 2001 22:56:19 -0800 (PST) Date: Wed, 07 Feb 2001 22:56:33 -0800 (PST) From: Robert Corbett Subject: Re: (SC22WG5.1995) Draft response to iterpretation 10 To: jkr@rl.ac.uk Cc: SC22WG5@dkuug.dk Reply-to: Robert Corbett Message-id: <0G8F00DFAF9V4N@mpkmail.eng.sun.com> MIME-version: 1.0 X-Mailer: dtmail 1.2.1 CDE Version 1.2.1 SunOS 5.6 sun4u sparc Content-type: TEXT/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-MD5: xfJ0MCwz8zmoOi9xev3TpQ== The proposed draft response has the drawback that it makes namelist input ambiguous. Consider the program PROGRAM MAIN TYPE REC LOGICAL T END TYPE TYPE(REC) :: L CHARCATER*20 STR(5) LOGICAL T NAMELIST/ABC/L, STR, T READ (*, NML=ABC) WRITE (*, NML=ABC) END Suppose this program is presented the input &ABC STR = L% L% T = T / Under the proposed draft response, the input could be equivalent to STR(1) = 'L%' STR(2) = 'L%' T = .TRUE. or it could be equivalent to STR(1) = 'L%' L%T = .TRUE. One way of resolving the ambiguity would be to require the form of a value that includes a comma to to be used between the last value assigned to an array and a following name when the number of values assigned to the array is less than the number of elements in the array. For the example presented above, the first interpretation would be chosen under this resolution. This resolution of the ambiguity has the tiny drawback of being incompatible with every implementation on which I tried it. Yours truly, Robert Corbett > Date: Wed, 07 Feb 2001 19:41:34 +0000 (GMT) > From: John Reid > Subject: (SC22WG5.1995) Draft response to iterpretation 10 > To: SC22WG5@dkuug.dk > MIME-version: 1.0 > > NUMBER: 000010 > TITLE: Meaning of embedded blanks in namelist input name > KEYWORDS: NAMELIST, optional qualification, name, input > DEFECT TYPE: Interpretation > STATUS: J3 consideration in progress > > BACKGROUND: > In running some older NAMELIST tests, a test case was encountered that has > embedded blanks within the "optional qualification" following a namelist group > object name: > > CHARACTER*10 string > NAMELIST /junk/ string > > WRITE(9,*) ' $junk string( : ) = ''1234567890'' /' > REWIND(9) > READ(9,junk) > > IF (string .NE. '123457890') THEN > PRINT *, 'string NE 1234567890, string = "', string, '"' > PRINT *, 'String test FAILED' > ELSE > PRINT *, 'String test PASSED' > END IF > > END > > While studying the standard to determine if the above program was standard- > conforming or not, some questions arose about the use of "name" and embedded > blanks in the namelist section 10.9.1.1. Among them were: Since a blank is a > delimiter, should it be allowed to be embedded in a variety of places in a > namelist input record that are not currently described by the standard? Do we > want to strain namelist input scanning more than a reasonable amount? > > In normal Fortran terminology, the term "name" does not include subobject > qualification. In section 2.5.1 Name and designator, lines 2 through 5, the > standard states: > > A name is used to identify a program constituent, such as a program unit, > named variable, named constant, dummy argument, or derived type. The rules > governing the construction of names are given in 3.2.1. A subobject > designator is a name followed by one or more of the following: component > selectors, array section, array element selectors, and substring selectors. > > In section 10.9.1 Namelist Input, lines 13 to 16, the standard states: > > In each name-value subsequence, the name shall be the name of a namelist > group list item with an optional qualification and the name with the optional > qualification shall not be a zero-sized array, a zero-sized array section, or > a zero-length character string. The optional qualification, if any, shall > not contain a vector subscript. > > In section 10.9.1.1 Namelist group object names, lines 32 and 33, the > standard states: > > The name in the input record may be preceded and followed by one or more > optional blanks but shall not contain embedded blanks. > > QUESTION: > > (1) Does Section 2.5.1 mean that the optional qualification described in the > 10.9.1 is not part of the name for namelist input? > > If the optional qualification is not part of the name, there seem to be no > rules for where blanks and end-of-record may occur within the optional > qualification. > > Also note that size of the name and the optional qualification together > may be longer than the size of an input record if there are multiple levels > of structure component qualification in a structure component reference. > > > (2) Are embedded blanks allowed within substring and subscript qualifications > in the namelist input? May an END-OF-RECORD occur in these same places? > > (3) More specifically, are embedded blanks/END-OF-RECORD allowed in the > following places in namelist input? > > 1. Between the name and the left parenthesis of either a substring or > subscript qualification? > > e.g., string (3:4) = '123' > > 2. Between tokens within the parenthesized qualifier? > > e.g., string( 3:4) = '123' > e.g., string( 3:4 ) = '123' > e.g., string( 3: 4 ) = '123' > e.g., string( 3 : 4 ) = '123' > > e.g., string( : ) = '123' > > 3. Between the two sets of parentheses for array and substring notation? > > e.g., string ( : ) ( : ) = '123' > > 6. Within the two subscripts or start and end values themselves? > > e.g., string ( 2 0 : 3 0 ) = '123' > > (4) Are embedded blanks allowed within a reference to a structure? May an > END-OF-RECORD occur within this reference? > > e.g., LONG__NAME % LEVEL1 ( 2 0 : 3 0 ) % string = '123' > > (5) Section 10.9.1.1, lines 32 and 33 currently state: > > The name in the input record may be preceded and followed by one or > more optional blanks but shall not contain embedded blanks. > > Should the above lines have an addition along the following lines: > > Blanks shall not precede the left parenthesis of a substring or subscript > qualification. Blanks may follow the left parenthesis or precede the > right parenthesis of the substring or subscript qualification but shall > not be embedded within the subscript or substring themselves. The end > of record shall not occur within any part of the substring or subscript > qualification. Blanks may occur between a subscript and a substring > qualification. > > Note to committee: > > The above addition will then allow ( : ) and ( 2:3 ) but will not > allow ( 1 0 : 2 0 ). Blanks will be allowed in between the subscript > and substring reference: ( 1:2 ) ( 3:4 ). > > The following change is harder. If the derived type qualification is so > long that it will not fit in one record, there are two choices that come > to mind: > > * state that the input record must be long enough to contain the entire > reference > > * allow the user to break up the structure reference to be able to > specify it within an input record. > > The latter ability could be added to the standard via additional text along > the following lines: > > Blanks shall not be embedded within the optional qualification provided > for a structure reference. However, an end-of-record may occur after > a percent (%) separator in an input record. The name may continue in > the next record. > > This will allow a break at such places as: > > LONG__NAME%LEVEL1(20:30)%EOR > string = '123' > > where EOR stands for end-of-record. > > ANSWER: > > The intention is that the form of namelist input should mirror that of > free source form (3.3.1), as in made clear in line 5 of 10.9.1.1 > [179:24]: 'the designator of a subobject of that array, using the > syntax of subobject designators (R602).' Spaces are not permitted > within names or constants so the constants 2 0 and 3 0 in examples (3) > 6 and (4) above are not permitted. Otherwise, all the above examples > are permitted. > > The final example, where a subobject designator is split between lines > at a percent sign, is permitted since (see the first paragraph of > clause 10.9) the end of a record has the same effect as a blank > character. > > Unfortunately, the term 'name' is sometimes used in this part of the > standard when 'name or designator' is intended. This was not intended > in the last sentence of 10.9.1.1 and an edit is provided to make the > intention clear. > > EDITS: > > Replace the last sentence of subclause 10.9.1.1 [179:32-33] by > > In the input record, a group object name, component name, or constant > within a subobject designator may be preceded and followed by one or > more optional blanks but shall not contain embedded blanks. > > SUBMITTED BY: Joanne Brixius / Larry Rolison > HISTORY: J3/97-253 m143 submitted