From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Thu Sep 5 08:36:35 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 5B3D335725C; Thu, 5 Sep 2013 08:36:35 +0200 (CEST) Delivered-To: sc22wg5@open-std.org Received: from nag-j.co.jp (nag-j.co.jp [111.68.142.10]) by www.open-std.org (Postfix) with ESMTP id 6E69A357112 for ; Thu, 5 Sep 2013 08:36:17 +0200 (CEST) Received: from Maru6 (218-42-159-105.cust.bit-drive.ne.jp [218.42.159.105]) (authenticated bits=0) by nag-j.co.jp (8.14.5/8.14.5) with ESMTP id r856aCGb080843 for ; Thu, 5 Sep 2013 06:36:16 GMT (envelope-from malcolm@nag-j.co.jp) Message-ID: <6BC195BF857F421D97EDB0E5722DEE16@Maru6> From: "Malcolm Cohen" To: "WG5" Subject: Interp ballot Date: Thu, 5 Sep 2013 15:36:09 +0900 Organization: =?iso-2022-jp?B?GyRCRnxLXBsoQk5BRw==?= MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-2022-jp"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 15.4.3555.308 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3555.308 Sender: owner-sc22wg5@open-std.org Precedence: bulk The following Fortran 2008 interpretations are being balloted: Yes No Number Title -Y- --- F03/0030 IEEE divide by zero -C- --- F03/0047 Polymorphic arguments to intrinsic procedures -Y- --- F03/0053 The BIND attribute for C_PTR and C_FUNPTR -Y- --- F03/0064 Recursive declaration of procedure interfaces -Y- --- F03/0100 Error in field width for special cases of signed INFINITY output -C- --- F03/0139 Functions returning procedure pointers -Y- --- F08/0071 Vector subscript target -N- --- F08/0075 Pointer function reference as variable in assignment -N- --- F08/0076 Pointer function reference in READ Subsumed by F07/0075 -Y- --- F08/0083 Type parameter default expressions allow circular dependence -Y- --- F08/0084 Pointer arguments to PURE functions -Y- --- F08/0085 Problems with PARAMETERs -C- --- F08/0086 Implied-shape and separate PARAMETER statement -Y- --- F08/0087 Mixed-kind character assignment -Y- --- F08/0088 Can ALLOCATE with SOURCE= have side-effects in a PURE proc? -Y- --- F08/0089 Variable-denoting functions change existing semantics -C- --- F08/0090 What restrictions apply to initialization and PARAMETER? COMMENT on F03/0047: (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." COMMENT on F03/0139: (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. NO VOTE on F08/0075 and F08/0076: 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. COMMENT on F08/0086: 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). COMMENT on F08/0090: (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." Cheers, -- ................................Malcolm Cohen, Nihon NAG, Tokyo.