From owner-sc22wg5  Mon Nov 26 18:07:13 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 SAA53784
	for <SC22WG5@dkuug.dk>; Mon, 26 Nov 2001 18:07:13 +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 RAA17429
	for <SC22WG5@dkuug.dk>; Mon, 26 Nov 2001 17:07:09 GMT
Received: (from jkr@localhost)
	by jkr.cc.rl.ac.uk (8.8.8+Sun/8.8.8) id RAA24598
	for SC22WG5@dkuug.dk; Mon, 26 Nov 2001 17:09:32 GMT
Date: Mon, 26 Nov 2001 17:09:32 GMT
From: John Reid <jkr@rl.ac.uk>
Message-Id: <200111261709.RAA24598@jkr.cc.rl.ac.uk>
To: SC22WG5@dkuug.dk
Subject: Results of the ballot on interpretations (draft)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

Dear WG5,

Here is my draft of the paper with the results of the ballot on
interpretations.  Please let me know within 3 days if you find any
mistakes or omissions.

Best wishes,

John. 

                                           ISO/IEC JTC1/SC22/WG5-N1470
 
               Results of the ballot on interpretations

                       John Reid, 26 November 2001

            7   9  26  27  66  67  71  86  91  95  97     
Dedo        y   y   y   y   y   y   y   y   y   y   y    
Gorelik     y   y   y   y   y   y   y   y   y   y   y  
Kruyt       y   y   y   y   y   y   y   y   y   y   y   
Long        y   y   y   y   y   y   y   y   y   y   y   
Mahonen     y   y   y   y   y   y   y   y   y   y   y   
Maine       y   y   y   y   y   y   y   y   y   y   y  
Martin      y   y   y   y   y   y   y   y   y   y   y   
Meadows     y   y   y   y   y   y   y   y   y   y   y   
Morgan      y   y   y   y   y   y   y   y   y   y   y   
Muxworthy   y   y   y   y   y   y   y   y   y   y   y    
Schoenauer  y   y   y   y   y   y   y   y   y   y   y    
Snyder      y   y   y   y   y   y   yc  y   y   y   y    
Takata      y   y   y   y   y   y   y   y   y   y   y    
Whitlock    y   y   y   y   y   y   y   y   y   y   y    


           f90 f90 f90 f90 JP  JP  JP  JP  JP  JP 
           164 209 211 212 04  05  08  16  17  31  
Dedo        y   y   y   y   y   y   y   y   n   y    
Gorelik     y   y   y   y   y   y   y   y   y   y     
Kruyt       y   yc  y   y   y   y   y   y   yc  y      
Long        y   y   y   y   y   y   y   y   n   y      
Mahonen     y   y   y   y   y   y   y   y   y   y     
Maine       y   yc  y   y   y   y   y   y   y   y    
Martin      y   y   y   y   y   y   y   y   y   y     
Meadows     y   y   y   y   y   y   y   y   y   y     
Morgan      y   y   y   y   y   y   y   y   y   y     
Muxworthy   y   y   y   y   y   y   y   y   y   y      
Schoenauer  y   y   y   y   y   y   y   y   y   y      
Snyder      y   yc  y   y   y   y   y   y   y   y      
Takata      y   y   y   y   y   y   y   y   y   y      
Whitlock    y   y   y   y   y   y   y   y   y   y     


...........................................................

All items except JP/17 passed unanimously. JP/17 passed by 12-2. 
For F90/209 the suggested changed has been accepted. 

The comments and reasons for the NO votes are appended, together with 
my responses.
 
...........................................................


REASONS FOR NO VOTES

JP-17  Long and Brixius

There is no statement in the standard forbidding a name from appearing
more than once in a NAMELIST. There is no logical reason for adding
this restriction. The sequence of names in a NAMELIST represents an
I/O list. A name can appear more than once in other forms of I/O
lists. We should not have a different rule for NAMELIST.

JP-17  Dedo

I agree with the comments of Bill Long.  I also noticed that the answer
to this interpretation did not give any reasoning for the conclusion.

JKR response: This has already been reconsidered once by J3. 



COMMENTS

71  Snyder

In the edit
[45:38+] Add to end of paragraph:
"The character length of an ac-value in an <ac-implied-do> whose
 iteration count is zero shall not depend on the value of the implied
 DO variable and shall not depend on the value of an expression that
 is not an initialization expression."

the "and shall not depend on the value of an expression that is not an
initialization expression."

seems not to be necessary.

JKR response: An example that illustrates the need for this text 
may be constructed from QUESTION 3 by changing 'f(i)' in the write
statement to 'f(n)'. 


F90/000209  Snyder

  "another input/output statement or stop statement" allows to be read
  "another ... stop statement".  Insert "a" after "or" in the edit.

F90/000209  Kruyt

Insert "a" after "or" in the edit. (see Van Snyder's comment)

F90/000209  Maine

I agree with Van's suggested minor wording improvement to the edit.

JKR response: I have made this change. 


JP-17  Kruyt

In my opinion this addition must become a constraint in the next Fortran
standard.

JKR response:  J3, please consider this suggestion.  









