From LJM@SLACVM.BITNET Tue Mar 22 11:22:00 1994 Received: from vm.uni-c.dk by dkuug.dk with SMTP id AA29528 (5.65c8/IDA-1.4.4j for ); Wed, 23 Mar 1994 04:24:42 +0100 Message-Id: <199403230324.AA29528@dkuug.dk> Received: from vm.uni-c.dk by vm.uni-c.dk (IBM VM SMTP V2R2) with BSMTP id 4714; Wed, 23 Mar 94 04:24:50 DNT Received: from SLACVM.SLAC.STANFORD.EDU by vm.uni-c.dk (Mailer R2.07) with BSMTP id 6473; Wed, 23 Mar 94 04:24:47 DNT Received: by SLACVM (Mailer R2.08 R208004) id 5434; Tue, 22 Mar 94 19:23:40 PST Date: Tue, 22 Mar 1994 19:22 -0800 (PST) From: "Len Moss" To: "SC22/WG5 Mailing List" Subject: Corrigendum 2 letter ballot response X-Charset: ASCII X-Char-Esc: 29 In-Reply-To: martin@ocfmail.ocf.llnl.gov -- 03/10/94 14:47 Subject: Corrigendum 2 letter ballot response Here is my ballot on Corrigendum 2. The reasons for my NO votes and the comments accompanying some of my YES votes are included at the end. Yo/wc N N865 Item o/xo/_o/ o/_o/ 000000b Minor edits and corrections to ISO/IEC 1539:1991 (E) o/_o/_o/ o/xo/ 000004 Blanks in format specifications in free source form o/xo/_o/ o/_o/ 000011 Multiple accessible defined operator and assignment interfaces o/xo/_o/ o/_o/ 000029 Class of a defined operator o/xo/_o/ o/_o/ 000030 Length of character literals in array constructors o/xo/_o/ o/_o/ 000033 Interface blocks with the same name in a program o/xo/_o/ o/_o/ 000039 Association of a pointer actual argument with a dummy argument o/xo/_o/ o/_o/ 000054 Resolving generic procedure references o/_o/_o/ o/xo/ 000058 Ambiguous use of "keyword" o/xo/_o/ o/_o/ 000071 Use association and common block names o/xo/_o/ o/_o/ 000073 Description of the MERGE intrinsic function o/xo/_o/ o/_o/ 000075 Interface blocks in block data o/xo/_o/ o/_o/ 000076 Attributes, properties, characteristics o/xo/_o/ o/_o/ 000077 Miscellaneous questions o/xo/_o/ o/_o/ 000082 Host association and generic names o/xo/_o/ o/_o/ 000087 PARAMETER statements and SAVE statements o/xo/_o/ o/_o/ 000089 Errors in the DATA statement description o/xo/_o/ o/_o/ 000092 Pointer and storage association o/xo/_o/ o/_o/ 000093 Scalar pointer function results o/_o/xo/ o/_o/ 000097 Specification expression o/xo/_o/ o/_o/ 000099 Generic interfaces o/_o/_o/ o/xo/ 000100 ASSOCIATED intrinsic and zero-sized objects o/xo/_o/ o/_o/ 000102 Returned value for INQUIRE POSITION= on an empty file o/xo/_o/ o/_o/ 000105 Parallel evaluation of operands and arguments o/xo/_o/ o/_o/ 000106 Multiple USE of modules; renaming rules o/xo/_o/ o/_o/ 000108 Referencing disassociated pointers o/xo/_o/ o/_o/ 000111 Array constructors in masked assignment statements o/xo/_o/ o/_o/ 000112 Sequence derived type external functions o/xo/_o/ o/_o/ 000113 Ordering of array specification and initialization o/xo/_o/ o/_o/ 000116 Scoping units and statement labels o/xo/_o/ o/_o/ 000117 Use of MODULE PROCEDURE statement in internal procedures o/xo/_o/ o/_o/ 000123 Result of INT(A) not equal to A for non-default integers o/xo/_o/ o/_o/ 000124 Result of LBOUND for assumed-size arrays o/xo/_o/ o/_o/ 000126 Character Entry statements and Partial Association o/_o/_o/ o/xo/ 000127 Is a module a global entity? o/xo/_o/ o/_o/ 000128 Use associated generic names and renaming o/_o/_o/ o/xo/ 000129 Array constructors in initialization expressions o/xo/_o/ o/_o/ 000130 Multiple statements on line with END statement o/xo/_o/ o/_o/ 000131 Formatted Input and Kind Type Parameters o/xo/_o/ o/_o/ 000132 SYSTEM_CLOCK intrinsic conformance requirements o/xo/_o/ o/_o/ 000133 Definition of RtokenS as used in section 3.3.1 o/_o/xo/ o/_o/ 000144 Specification expressions and implicit typing. o/xo/_o/ o/_o/ 000150 Undefinition of implied-DO variables in I/O statements o/_o/xo/ o/_o/ 000151 Defined Operators with POINTER Operands o/xo/_o/ o/_o/ 000152 Processor dependent values for list and namelist directed output o/_o/xo/ o/_o/ 000153 Defined Operations, dummy arguments INTENT(IN) o/_o/_o/ o/xo/ 000155 Multiple USE statements, rename and only lists. o/xo/_o/ o/_o/ 000157 LBOUND and UBOUND return values o/xo/_o/ o/_o/ 000170 Argument Keywords and Intrinsic Procedures Here are my reasons and comments: 004 N Moss I agree with John Reid: it is inappropriate to change the definition of "keyword" in a corrigendum when a simpler fix will do. I prefer his alternative response to this item. 058 N Moss I agree with John Reid: most of the edits in this response are unnecessary. I prefer John's alternative response. 097 Y Moss The proposed edits result in doubly-nested lists which (doubly ;-) violate the style guidelines. I suggest preserving the text of the edits, but collapsing the secondary ('a), 'b)',...) and tertiary ('1)', '2)',...) lists into straight text, with a semicolon at the end of each secondary point and a comma at the end of each tertiary point. 100 N Moss I agree with John Reid and others: if the two arguments to ASSOCIATED are zero-sized and otherwise satisfy the requirements (type, shape etc.), the result should be true, just as a zero-sized array is always considered to be defined. 127 N Moss Answer 3 is confusing. The first sentence, "No, a module can not be referenced..." seems to say that the USE statement in the example is invalid. The second sentence, however, implies that the example is valid and that the REAL variable, ABC, is simply inaccessible in subroutine SUB. 129 N Moss In light of the example pointed out by Janice Shepherd, e.g., INTEGER A(3) PARAMETER (A = (/ (ABS( (/ I /)), I= 1,3) /) ) I think this response should be reversed and edits supplied to permit the simpler case, INTEGER A(3) PARAMETER ( A = (/ (ABS(I), I=1,3) /) ) 144 Y Moss I would prefer to drop the last paragraph of the discussion, which suggest that we might consider a future change to relax one of the 'define-before-use' restrictions on the DATA statement. 151 Y Moss I do not object to this interpretation for Fortran 90. However, it is based on a rather arbitrary restriction against the INTENT attribute for dummy pointers. As I explain in more detail in my NO vote on item 125 in the separate X3J3 ballot on X3J3/94-006Ar1, I think we may want to revisit this restriction for Fortran 95. 153 Y Moss In edit 5 the line number should 6. 155 N Moss I agree with John Reid: the first three edits are unnecessary in a corrigendum. -- Leonard J. Moss o/ My views don't necessarily Stanford Linear Accelerator Center, MS 97 o/ reflect those of SLAC, P.O. Box 4349; Stanford, CA 94309 o/ Stanford or the DOE