From J.L.Schonfelder@liverpool.ac.uk Tue Apr 12 14:44:08 1994 Received: from mailhub.liverpool.ac.uk (mail.liv.ac.uk) by dkuug.dk with SMTP id AA24605 (5.65c8/IDA-1.4.4j for ); Tue, 12 Apr 1994 14:44:25 +0200 Received: from 138.253.31.129 by mailhub.liverpool.ac.uk with SMTP (PP) id <21997-0@mailhub.liverpool.ac.uk>; Tue, 12 Apr 1994 13:44:09 +0100 From: "Dr.J.L.Schonfelder" Message-Id: <9404121244.AA16492@uxd.liv.ac.uk> Subject: corrigendum 2 ballot To: SC22WG5@dkuug.dk (SC22/WG5 members) Date: Tue, 12 Apr 1994 13:44:08 +0100 (BST) X-Mailer: ELM [version 2.4 PL23] Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Content-Length: 3400 X-Charset: ASCII X-Char-Esc: 29 I vote yes to all items except for those below: 00004 NO I believe this to be the wrong fix. Two letter edit descriptors should no more be treated as two separate tokens than say the concatenate operator // or the exponentiate ** 00071 NO I dislike this whole notion. The point of allowing COMMON in modules was to provide for a transition from the use of common for global data to modules. I do not believe it was the intent to allow multiple definitions of the same common block to be accessible in the same program unit. In a sence these examples are tantamount to allowing SUBROUTINE USER() COMMON/BLOCK/A,B,C COMMON/BLOCK/X,Y,Z As such I find it definitely undesirable and I do not believe we intended to allow this. 00082 YES In this particular case the declaration of the array F does mask any reference to the overloaded name F where such a reference would be to a function with a single interger argument. However, if the internal subprogram had a reference F(0.0D0) and an overload of F existed with a single double precision argument this should still be a valid reference to that function and not an invalid reference to the array. 00100 NO I do not believe the undefined result specified in the answer to this question was the intent of the committee, nor is it particularly user friendly. The object of including "zero-sized" facilities was to make "edge cases" follow naturally as limiting cases of non-zero situations. The sudden undefining of this particular case of ASSOCIATED(PTR,TGT) is not in that spirit. Such a reference should deliver true if the two arguments refer to the same zero-sized object (suitably defined). If the fragment P1=>A(:,1:N) PRINT *, ASSOCIATED(P1,A(:,1:N)) was in a loop decrementing N, it would be extremely surprising for this to be undefined when N=0. 00127 NO This is plain silly! A module name cannot be confused with any other name local or otherwise. It can only appear in a distintuished context on a USE statement. This is further example of the nonsence caused by the mess we have in the class of names definitions. This simple underlines the mess it does not correct the errors that the mess makes. We should fix the cause not perpetuate the disease. 00151 NO If this is how the standard reads, this was a mistake in the drafting and this implication was not properly seen. This was an inadvertent error and it should be fixed. We should allow pointer operands to user defined operators we did NOT intend to prohibit them. 00153 NO See 151, this needs to be fixed as clearly was a mistake in the existing drafting. Jeanne, is this sufficient or do you want the formal paper ballot returned as well? -- Dr.J.L.Schonfelder Director, Computing Services Dept. University of Liverpool, UK Phone: +44(51)794 3716 FAX : +44(51)794 3759 email: jls@liv.ac.uk