From jkr@jkr.cc.rl.ac.uk Mon Oct 9 14:48:32 2000 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 OAA27033 for ; Mon, 9 Oct 2000 14:48:31 +0200 (CEST) (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 NAA20459 for ; Mon, 9 Oct 2000 13:48:31 +0100 Received: (from jkr@localhost) by jkr.cc.rl.ac.uk (8.8.8+Sun/8.8.8) id NAA11404 for SC22WG5@dkuug.dk; Mon, 9 Oct 2000 13:49:41 +0100 (BST) Date: Mon, 9 Oct 2000 13:49:41 +0100 (BST) From: John Reid Message-Id: <200010091249.NAA11404@jkr.cc.rl.ac.uk> To: SC22WG5@dkuug.dk Subject: Result of ballot on corrigendum 1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Dear WG5 members, A draft of document N1420, the result of the ballot on corrigendum 1, is attached. Please let me know within one week (by October 16) if I have failed to include your vote or if there is anything wrong with it. The ballot passed by 6 votes to 4. I have made the following substantive changes in response to the comments and no votes: Page 56, extra edit: In line 1 of the final paragraph of the subclause, replace `nonconstant specification' with `not initialization'. Page 283. The clause that commences 'if it is invoked' in the third line of the new text changed to 'if it is invoked as a function in the inner scoping unit, its type and type parameters shall be explicitly declared in a type declaration statement in the host scoping unit or it shall be used as a procedure in the host scoping unit'. These changes address all the no votes. In addition, I have made these minor changes: For pages 54 and 56 the line numbers (that will not appear in the actual corrigendum) have been corrected. 'Pages 89, 90' changed to 'Pages 89 and 90'. For page 266, quotes placed around 'Result value.' in the first line. 'Page 280' changed to 'Pages 280 and 281'. The revised corrigendum in on the server as N1421. To allow you to comment, I will wait for one week (that is until 16 October) before forwarding this (with line and interpretation numbers removed) to the SC22 Secretariat. Best wishes, John. .................. ISO/IEC JTC1/SC22/WG5-1420 Result of the ballot on corrigendum 1 John Reid, 9 October 2000 Kruyt YES, with comment Maine YES, with comment Martin YES, with comments Meadows NO Muxworthy YES Snyder YES, with comment Steidel et al NO Takata NO Warnock YES Zongaro et al NO Totals 6 4 Comments and reasons for no votes: Kruyt ~~~~~ I miss the following edit of interp 70: Page 56, Subclause 5.1.2.4.4 In the first line of the final paragraph of the subclause, replace "nonconstant specification expressions" with "not initialization expressions". Maine ~~~~~ Henry Zongaro's comments seem worth study. I have no separate comments of my own. Martin ~~~~~~ Yes, if the points raised by Erik Kruyt and Henry are addressed. I suggest a few minor changes to the edit instructions: - The Page 69 edit instructions should begin "In lines 3 and 4" rather than "In line 3". - The Page 266 edit instructions should begin 'After "Result Value.",' (quotes missing) - The Page 289 edit instructions for item (ii), add "of the second paragraph" after "last line" Not really necessary, but there is a "corresponding" in the penultimate line of the first paragraph that I stumbled on the first time I read it. Meadows ~~~~~~~ I agree with IBM's comments regarding minor rewording and the two 70 and 80. Snyder ~~~~~~ What should have happened is to change "nonconstant specification" at [56:32] to "not an initialization". If this is so, should it be the subject of a future corrigendum, or should we delay the present one? I have already voted "yes" on Corrigendum 1, because although it appears to be incomplete, it does not appear to be incorrect. Steidel, Brixius and Long ~~~~~~~~~~~~~~~~~~~~~~~~~ We agree that the changes recommended by IBM for 70 and 80 are needed. Takata ~~~~~~ I agree with Henry's two minor comments and his substantive comment to Interpretation 80. I can accept his comment on Interpretation 70, but can live without it. Zongaro, Li, and Gooderham ~~~~~~~~~~~~~~~~~~~~~~~~~~~ We had the following minor comments: o At the top of page 3, "Pages 89, 90" should be "Pages 89 and 90" for consistency. o At the top of page 4, "Page 280" should be "Pages 280 and 281". (The edits span two pages.) We had the following substantive comments: o The edit to [56:32] from Interpretation question 70 appears to have been missed. We believe the following additional edit to 5.1.2.4.4 is required: In the final paragraph of the subclause, replace "nonconstant specification" with "not initialization" o We believe that the response to Interpretation question 80 is overly restrictive. The edit to subclause 14.6.1.3 states, in part, that "if it is invoked as a function in the inner scoping unit, its type and type parameters shall be explicitly declared in a type declaration statement in the host scoping unit." In the following example, because IF is implicitly declared in P, it cannot be accessed via host association according to the preceding rule. PROGRAM P EXTERNAL :: IF, OK_F, BAD_F, EXTSUB INTEGER :: OK_F I = IF() CALL EXTSUB CALL SUB CONTAINS SUBROUTINE SUB I = IF() ! Can't do this ! R = BAD_F() ! Can't do this R = OK_F() ! OK CALL EXTSUB ! OK END SUBROUTINE SUB END PROGRAM P We believe that the text quoted above should read: "if it is invoked as a function in the inner scoping unit, its type and type parameters shall be explicitly declared in a type declaration statement in the host scoping unit, or it shall be used as a procedure in the host scoping unit." That would make the example program unit standard conforming. My apologies for failing to notice this earlier. and later: You asked, "But can you explain why these two edits are necessary?" I can think of two reasons for applying the two edits in question: 1) All of the other edits for interpretation 70 eliminate uses of the terms "constant specification expression" and "nonconstant specification expression". If these two edits are not applied, I believe we would leave the only remaining instances of those terms. For consistency with usage elsewhere, I think both edits should be applied. 2) The case in which the change in wording could be considered to be necessary is obscure at best. Consider the following example. SUBROUTINE SUB(A, B, I) INTEGER A(I*2, *), B(NINT(COS(ACOS(0.5))), *) ... END SUBROUTINE SUB The expression I*2 is a nonconstant specification expression, while NINT(COS(ACOS(0.5))) is a constant specification expression; neither is an initialization expression. If we leave the wording unchanged, the bounds of A are determined at entry to SUB, but it's not specified where the bounds of B are determined. It could be that the value of NINT(COS(ACOS(0.5))) would be different at different points in the subroutine's execution - particularly if the implementations of COS and ACOS were sensitive to rounding mode. Failing to specify the point at which the values of the bounds of B must be determined makes this admittedly pathological case even more difficult to deal with. Regarding the proposed change to the edits to 14.6.1.3, I'm not sure whether the interpretation process makes clear how a situation like this should be handled. However, I'd much rather see interpretation 80 go back to J3 for further consideration. The current set of edits in the response to interpretation 80 were carefully thought through; I wouldn't want to see my hastily composed refinement enter the corrigendum, only to have someone else uncover a problem with it after publication.