From jkr@jkr.cc.rl.ac.uk Wed Feb 7 20:39:50 2001 Received: from nameserv.rl.ac.uk (nameserv.rl.ac.uk [130.246.135.129]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id UAA29674 for ; Wed, 7 Feb 2001 20:39:50 +0100 (CET) (envelope-from jkr@jkr.cc.rl.ac.uk) Received: from jkr.cc.rl.ac.uk (jkr.cc.rl.ac.uk [130.246.8.20]) by nameserv.rl.ac.uk (8.8.8/8.8.8) with ESMTP id TAA22223 for ; Wed, 7 Feb 2001 19:39:49 GMT Received: (from jkr@localhost) by jkr.cc.rl.ac.uk (8.8.8+Sun/8.8.8) id TAA09470 for SC22WG5@dkuug.dk; Wed, 7 Feb 2001 19:41:34 GMT Date: Wed, 7 Feb 2001 19:41:34 GMT From: John Reid Message-Id: <200102071941.TAA09470@jkr.cc.rl.ac.uk> To: SC22WG5@dkuug.dk Subject: Draft response to iterpretation 10 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" 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