From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Fri Sep 6 10:58:37 2013 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www.open-std.org Received: by www.open-std.org (Postfix, from userid 521) id 3638B3572C0; Fri, 6 Sep 2013 10:58:37 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from mk-filter-2-a-1.mail.uk.tiscali.com (mk-filter-2-a-1.mail.tiscali.co.uk [212.74.100.53]) by www.open-std.org (Postfix) with ESMTP id 60B8635719B for ; Fri, 6 Sep 2013 10:58:21 +0200 (CEST) X-Trace: 1035524366/mk-filter-2.mail.uk.tiscali.com/B2C/$THROTTLED_STATIC/TalkTalk_Customer/2.97.127.39/None/John.Reid@stfc.ac.uk X-SBRS: None X-RemoteIP: 2.97.127.39 X-IP-MAIL-FROM: John.Reid@stfc.ac.uk X-SMTP-AUTH: X-Originating-Country: XX/UNKNOWN X-MUA: Mozilla/5.0 (Windows NT 5.1; rv:23.0) Gecko/20100101 Firefox/23.0 SeaMonkey/2.20 X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBAHKYKVICYX8n/2dsb2JhbAANTo0UtViEK4NGLCU9FhgDAgECAUsNCAKzHooYiEaOP4VXA5Ajh1KGGI5vgWg X-IPAS-Result: ApMBAHKYKVICYX8n/2dsb2JhbAANTo0UtViEK4NGLCU9FhgDAgECAUsNCAKzHooYiEaOP4VXA5Ajh1KGGI5vgWg X-IronPort-AV: E=Sophos;i="4.90,853,1371078000"; d="txt'?scan'208";a="1035524366" Received: from host-2-97-127-39.as13285.net (HELO [127.0.0.1]) ([2.97.127.39]) by smtp.tiscali.co.uk with ESMTP; 06 Sep 2013 09:57:43 +0100 Message-ID: <522999F7.1010400@stfc.ac.uk> Date: Fri, 06 Sep 2013 10:01:43 +0100 From: John Reid User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:23.0) Gecko/20100101 Firefox/23.0 SeaMonkey/2.20 MIME-Version: 1.0 To: WG5 Subject: Interpretations ballot 6 Content-Type: multipart/mixed; boundary="------------020308060606020409020203" Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multi-part message in MIME format. --------------020308060606020409020203 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit WG5, Here is the first draft result of interpretations ballot 6. Please tell me if I have missed your vote or made any errors in my inclusion of it. I have allocated provisional results by this rule: if all votes Y, result is Y else if there are no N votes, result is C else result is ? I would be most grateful if /INTERP would make suggestions for the ? results and decide on how to treat the Cs. In the final version of N1990, I would like to change each ? to Y, C, or N. Also, it would be good to include decisions on Cs. I believe that our decision in Delft was to submit Corrigendum 3 before the end of 2013, but I find this statement in our strategic plan (N1979): "There will be a WG5 interpretations ballot starting in July 2013 and the third corrigendum to Fortran 2008 will be constructed within a year. A fourth corrigendum might be constructed in 2014." Does anyone disagree that we should aim to submit Corrigendum 3 before the end of 2013? I said that this was our plan in my report to SC22. Best wishes, John. --------------020308060606020409020203 Content-Type: text/plain; charset=windows-1252; name="N1990-1.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="N1990-1.txt" ISO/IEC JTC1/SC22/WG5 N1990-1 Result of the interpretations ballot 6, N1988 Key for the Result line: Y vote passes unconditionally. C vote passes, subject to minor changes agreed by /INTERP. N vote fails. Returned to J3 for further work. ? result to be decided by the Convener and /INTERP. F03/ F03/ F03/ F03/ F03/ F03/ F08/ F08/ F08/ F08/ F08/ F08/ 0030 0047 0053 0064 0100 0139 0071 0075 0076 0083 0084 0085 Bader C Y Y Y Y Y Y Y - Y Y Y Chen Y Y Y Y Y Y Y Y Y Y Y Y Cohen Y C Y Y Y C Y N N Y Y Y Corbett N Y Y Y Y Y Y N - Y Y Y Long Y C Y Y Y C Y Y Y Y Y Y Muxworthy Y Y C Y Y C Y Y Y C Y Y Reid Y Y Y Y Y Y Y Y Y Y Y Y Snyder Y Y Y Y Y N Y Y Y Y Y Y Whitlock Y Y Y Y Y Y Y Y Y Y Y Y Result ? C C Y Y C Y ? ? C Y Y F03/ F03/ F03/ F03/ F03/ 0086 0087 0088 0089 0090 Bader Y Y Y Chen Y Y Y Y Y Cohen C Y Y Y C Corbett Y Y Y N Y Long Y Y Y C Y Muxworthy C C Y Y C Reid Y Y Y Y Y Snyder C Y Y C N Whitlock Y Y Y Y Y Result C C C ? ? Comments, reasons for NO votes, and decisions of \INTERP. F03/0030 Bader comment: The edit for [403:10-11] says "It is processor-dependent whether it occurs in a real exponentiation with a negative exponent." For clarity, I suggest replacing this by "It is processor-dependent whether it occurs if the division appears as a that evaluates to a negative exponent in a real exponentiation." Corbett NO vote: The Fortran 2008 standard places no requirements on division in its description of IEEE_SUPPORT_DATATYPE (14.9p1, 14.11.24). The proposed edits require a processor to signal IEEE_OVERFLOW and IEEE_DIVIDE_BY_ZERO as specified by IEC 60559:1989, even though the processor is not required to produce the results specified by IEC 60559:1989 for normal operands returning normal operands unless IEEE_SUPPORT_DIVIDE is true. That makes no sense. For example, consider the case of an Intel 386 CPU with a 387 numeric coprocessor. A Fortran processor for such a system might implement the statement X = X/Y where X and Y are represented in the double-precision format of IEC 60559:1989 by extending the values of X and Y to extended precision performing the division and converting the result back to double-precision. The resulting division would not always produce the result required by IEC 60559:1989. It would also not signal exceptions as required by IEC 60559:1989. The text of the Fortran 2008 standard permits the processor to return true for IEEE_SUPPORT_DATATYPE(X) if it supports the requirements of 14.9, paragraph 1. Given the additional requirement added by the edits, the processor would not be permitted to return true for IEEE_SUPPORT_DATATYPE(X). .................................................................... F03/0047 Long comment: Answer 5 introduces a curious asymmetry if FSOURCE is not polymorphic and TSOURCE is polymorphic. In that case the result is polymorphic. However, the reference could just as easily been written merge(fsource, tsource, .not.mask) in which case the result is not polymorphic. Question 12(b) is really two questions, but there is only one Answer 12(b). [I realize that there is a clear pattern from previous answers, but this is a formal reply.] Question 13(d) is really two questions, but there is only one Answer 14(b). Cohen comment: (a) Although Bill Long correctly points out that MERGE is slightly assymetric if only one argument is polymorphic, but if only one argument is polymorphic the result type is known precisely and is always the declared type, so this is not a polymorphism that makes a difference other than allowing one to use it in SELECT TYPE. And why do SELECT TYPE when you know the answer. One might imagine that also the standard is clear and unambiguous, the answer for MERGE is unhelpful. There are at least two reasonable, symmetric and consistent things to do here: (i) MERGE is polymorphic if and only if both TSOURCE and FSOURCE are polymorphic; (ii) the "types should be the same" should apply only to the declared type, and MERGE should be polymorphic if either or both of TSOURCE and FSOURCE are the same; this would seem to be the most useful definition, but it would require an edit. Either of these would result in edits to the standard. Perhaps we should pull Q5 and A5 out of this interp, and make a new interp of it. Note that it is too late to change F2003 though! (b) I agree with Bill Long that the answer to 12(b) should state that the declared and dynamic types of the result are those of the argument. (c) Bill says "13(d) is really two questions, but there is only one Answer 14(b)" (I think the latter is also supposed to be 13(d)!). To which I say yes, but the answer answers both questions... perhaps it would be better to make it clearer by saying "The result has the same declared and dynamic types as VECTOR, and is polymorphic if and only if VECTOR is polymorphic." .................................................................... F03/0053 Muxworthy comment: I prefer the first alternative at [431:6]. .................................................................... F03/0139 Long comment: Several of the edits change "result value" to "function result". I would expect the new "function result" text to be a hot link to the definition, as was the case with the replaced "result value". 5.1p2 seems to need more work that the edit for [87:9]. The wording about functions having type and rank is tied to them returning a data result. This is not relevant for a function that returns a procedure pointer that is associated with a subroutine. Perhaps fixed by adding "that returns a data result" after "A function" in [87:8]. Missed a "result variable" that crossed lines [307:16-17]. From the edit to C1290 [314:3] I assume that an elemental function is not allowed to return a procedure pointer. Should the initial answer (1b) start "Yes, a nonelemental function..."? In the edit for [433:7] I think the new text would be better as "result is a scalar variable". We are not proposing to allow a Fortran procedure pointer result here. Muxworthy comment: For the interp archive: "(1b)" and "(2b)" in the answers and the edits should be "(1)" and "(2)". "result variable" on [307:16-17] appears to have been missed. Snyder reason for NO vote: In the edit for [278:11], "... function result if it is a function" seems a bit redundant. Would "... function result" be good enough? If the procedure is a subroutine, it can't have a function result. In the edit for [310:5-6], the term "result names" is used. In other edits, the term "function result" is used instead of simply "result". Should "result names" here be "function result names", for consistency? [310:6-7] appears to imply that a function subprogram cannot define two functions that have procedure pointer results with different characteristics, or some that have procedure pointer results and others that have data object results (because a procedure pointer cannot be storage associated with another one, or with a variable). This ought to be clarified or repaired. If these are considered to be fodder for a different interpretation request, rather than further work necessary for the present one, this mark on my ballot can be changed to "yes with comment." The edit for [170:23+] could more economically combine the requirement with C804: " shall not be a variable or a function reference that returns a procedure pointer." Cohen comment: (a) Bill Long writes "I would expect the new "function result" text to be a hot link to the definition"; the editor replies that it cannot reasonably be (in an interp) since the Corrigenda are separate documents. (b) Bill Long suggests "adding "that returns a data result" after "A function" in [87:8]". I do not agree; the rank of a function that returns a data object is the rank of a data object, the rank of a function that returns a function object must therefore be the rank of the function object. (c) Bill Long suggests an extra edit for [307:16-17], I agree this should be "result variable" -> "result". (d) Bill Long comments "From the edit to C1290 [314:3] I assume that an elemental function is not allowed to return a procedure pointer. Should the initial answer (1b) start "Yes, a nonelemental function..."? I say no - it follows from the fact that an elemental function result cannot have the POINTER attribute, nothing to do with these edits. (e) I agree with Bill Long re [433:7]. (f) Van Snyder suggests the additional edit of deleting "if it is a function result" at [278:11]. I would prefer either to leave as is or to reword so the end of the sentence (from "and") says "and, if it is a function, the characteristics of its result". (g) Van Snyder suggests additional changes for [310:5-6]; I think it is better as is. (h) Van Snyder remarks "[310:6-7] appears to imply that a function subprogram cannot define two functions that have procedure pointer results with different characteristics" to which I say "of course, we have always required the results to have the same characteristics except for the single exception of the F77 storage-associated case". No clarification is required. (i) Van Snyder suggests merging C804a with C804, since these are doing different things - C804 is doing syntax disambiguation, C804a is making an actual requirement - I do not agree. .................................................................... F08/0075 and F08/0076: Corbett reason for NO vote on F08/0075 The proposed fix adds unnecessary inconsistencies to the language. The treatment of a pointer value that is the result of a function invocation should not depend on the syntactic form of the invocation. It would be better to deal with the syntactic ambiguities by adding constraints restricting the syntax of the variables on the left-hand side of an assignment and in input lists, and leave the semantics unchanged. In particular, the meaning of a selector should not depend on whether for form of the selector is a function reference or an operation. I objected to previous attempts to fix the ambiguities through syntax changes because the proposed changes were too difficult for users to understand. Prohibiting operations from being used as the variable on the left-hand side of an assignment or as a variable in an input list seems like the right fix for the ambiguities. There is no need to apply the restriction to cases such as selectors and specifiers. In general, if a data pointer value appears in a context that permits a data pointer value, it should be treated as a data pointer value. If a data pointer value appears in a context that permits a variable, but not a data pointer value, the pointer value should be treated as the target of the pointer. If a data pointer value appears in a context that requires a nonpointer value, the pointer value should be treated as the value of the target of the pointer. The Fortran 2008 standard hits the mark. The proposed interpretation moves the standard away from the aforestated principles. Cohen reason for NO vote: This whole area is a disaster. The feature should be deleted. Bob Corbett's contention that we should just change the syntax of assignment and READ has already been considered and rejected, it is not a new possibility. If people really want to do the "just change the syntax for those two cases" fix instead of the current "operator semantics" fix, they should vote NO. .................................................................... F08/0083 Muxworthy comment: For consistency the edit should be to 10-007r1. not 12-007. .................................................................... F08/0086 Cohen comment: The edits are complete, but the NOTES on the edits should be forwarded to the editor on completion for consideration for F2015 (as editorial improvement). Muxworthy comment: The notes suggest that the edits are not complete. Is another interp being raised to resolve the issue? Snyder comment: For the archive, in the question, replace "conforms to Fortran 77 to Fortran 2008" with something like "conforms to Fortran 77 through Fortran 2008" or "conforms to all Fortran standards from 2007 to 2008". .................................................................... F08/0087 Muxworthy comment: In the edit at [25:2+] "after p2" should be "after p3". .................................................................... F08/0089 Corbett reason for NO vote Questions Q1 and Q2 assume that if a pointer actual argument has the form of an expression and the corresponding dummy argument is a nonpointer dummy argument without the VALUE attribute, the dummy argument becomes argument associated with the value of the target of the value of the pointer actual argument. On the newsgroup comp.lang.fortran, Ian Harvey pointed out that the Fortran standards do not support that premise. Paragraph 2 of Clause 12.5.2.3 of the Fortran 2008 standard states If a nonpointer dummy argument without the VALUE attribute corresponds to a pointer actual argument that is pointer associated with a target, the dummy argument becomes argument associated with that target. Paragraph 8 of Clause 12.4.1.2 of the Fortran 2003 standard states Except in references to intrinsic inquiry functions, if the dummy argument is not a pointer and the corresponding actual argument is a pointer, the actual argument shall be associated with a target and the dummy argument becomes argument associated with that target. Paragraph 6 of Clause 12.4.1.1 of the Fortran 95 standard states If the dummy argument is not a pointer and the corresponding actual argument is a pointer, the actual argument shall be currently associated with a target and the dummy argument becomes argument associated with that target The paragraph added between paragraphs 3 and 4 of Clause 12.4.1.1 of the Fortran 90 standard by Corrigendum 2 states If the dummy argument is not a pointer and the corresponding actual argument is, the actual argument must be currently associated with a target and the dummy argument becomes argument associated with that target. That text was added as a result of interpretation F90/000039. In the examples given in questions Q1 and Q2, the actual argument fx() is a pointer actual argument corresponding to a nonpointer dummy argument. Therefore, the dummy argument becomes argument associated with the target of the pointer actual argument, which is the module variable x. The dummy argument does not become argument associated with the value of the target of the pointer. Thus, there is no semantic difference between Fortran 2008 and the previous standards in this regard. The answers and edits given for questions Q1 and Q2 are based on the same premise as the questions themselves and should be rejected. I asked people to compile and run the example programs given in questions Q1 and Q2 and variations of them using a variety of compilers. In most, but not all, cases, the results were consistent with the semantics stated in the Fortran standards, not with the semantics assumed by questions Q1 and Q2. Questions Q3 and Q4 are consistent with the standards, as are the corresponding answers and edits, but I do not care for the nature of the changes that will result if interpretation F08/0075 is passed. I think changing the language so that the form of a function reference determines its meaning is a mistake. Long comment: Twice in the edits appears "...a to a pointer function is regarded as a variable...". Should this be a "data pointer function"? Snyder comment: The term "pointer function" is not used as a noun, although "nonpointer function" is so used at [454:36]. I have a slight preference that "pointer function" in the edit for [24:11+] be replaced by "function that returns a pointer result" in both paragraphs. The same change ought to be made in the edits for [24:27+] and [25:6+] A parallel change ought to be made at [454:36], but that can be done editorially rather than within this interpretration. .................................................................... F08/0090 Muxworthy comment: I agree that Answer 1 for program m200c3_1 is strictly correct, but this creates an unfortunate difference from the DATA statement. Admittedly, an array constant is different from an array of constants but Note 5.29 has as an example: DATA ((SKEW (K, J), J = 1, K), K = 1, 100) / 5050 * 0.0 / This, or similar examples, have appeared in each standard since F77. The average user might expect PARAMETER to allow similar flexibility. Snyder reason for NO vote: One might argue that type, type parameters, and shape are covered by 5.2.3p1. In the examples, the cannot be "converted according to the rules for intrinsic assignment." Since this is impossible, no interpretation is established, and the examples are not conformant, and therefore no edits are needed. On the other hand, the description of the conversion in 5.2.3p1 needs to have some attention to cover the implied-shape case. Cohen comment: (a) Van Snyder objects "One might argue that type, type parameters, and shape are covered ... no interpretation is established, and the examples are not conformant" to which I reply "Indeed, precisely as the answer says." Van Snyder continues "and therefore no edits are needed." to which I reply "It is a poor standard that makes requirements via internal contradictions. These are defects." --------------020308060606020409020203--