From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Fri Sep 28 10:35:45 2012 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 238093569B4; Fri, 28 Sep 2012 10:35:45 +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 EA732356909 for ; Fri, 28 Sep 2012 10:35:42 +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 q8S8ZaJ4024354 for ; Fri, 28 Sep 2012 08:35:40 GMT (envelope-from malcolm@nag-j.co.jp) Message-ID: From: "Malcolm Cohen" To: "WG5" References: <20120914232724.BB7E5356938@www.open-std.org><20120925194814.26C3D356934@www.open-std.org> <20120928070255.A5ABE3569B2@www.open-std.org> In-Reply-To: <20120928070255.A5ABE3569B2@www.open-std.org> Subject: Re: [ukfortran] (SC22WG5.4805) (j3.2006) WG5 letter ballot 4 on Fortran 2008 interpretations Date: Fri, 28 Sep 2012 17:35:36 +0900 Organization: =?UTF-8?B?5pel5pysTkFH?= MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response 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 <<< ------------------------- F08/0048 C While I see no problem with implementing the feature as described in the proposed interpretation, I would agree to defer approval of the interpretation until after further consideration of Malcolm's objections. >>> That's just bizarre. I raised no new technical issue, having voted the same way at every previous vote (this interp originally went the other way - at that time I voted Yes, various people objected and now the interp goes the other way - so I have voted No twice already). It's not "further consideration" that is needed, it is a policy decision as to which way to go (the standard as written, or as Bill and John intended it to be written). I have had my say. >------------------------- >F08/0054 N > >I think that the proposed interpretation is a misinterpretation of >what was intended by paper 02-144. Paper 02-144 ***DID NOT INTEND TO MAKE A TECHNICAL CHANGE*** Not even a small one. (Either that or the authors secretly wanted a technical change and got it past the committee by subterfuge. I do not believe that is the case.) ... >The reason I am voting "no" on this interpretation is that the >proposed edits are incorrect. The text of the relevant portion of >the standard is also erroneous. > >I assume that the term "procedure identifier" is meant to include >operators and the names of procedures and procedure pointers. The >problem is that a generic identifier appears to fall under this >definition. A generic identifier does not have either implicit or >explicit interface. Huh? The edit says "Within the scope of a procedure identifier, THE PROCEDURE shall have an explicit interface" Nothing about generic identifiers having an explicit interface. > I do not see how the proposed edits apply in >the case of a generic identifier. Seems clear enough to me. >As I thought about the issue, I convinced myself that the property >of having implicit or explicit interface should apply only to the >names of procedures and procedure pointers, and not to procedures >themselves. Because of renaming, a single procedure can have more >than one name in a given scoping unit. The properties of each name >might be different. For example, a function F might be identified >by the names G and H in a scoping unit. The names of the dummy >arguments of G and H might be different. They would still both have explicit interfaces though... I am reluctant to completely rewrite the way the standard describes interfaces to procedures along the lines suggested, in an interp. I agree that the language could be better, but apart from not being entirely convinced that the suggested approach would actually be an improvement, I think that the right time for rewriting the whole method of description must be in a revision, not an interp. >------------------------- >F08/0063 N > >This interpretation upends the meaning of item (5) in Clause 10.7.2.1. No it does not. >A similar argument could be made against any application of item (5). That is completely untrue. F6.1 makes sense and according to item (5) will produce asterisks for large values e.g. 1e8. E10.2E2 makes sense and according to item (5) will produce asterisks for large enough values e.g. 1d200. >I am surprised anyone thinks that editing under an F4.5 edit >descriptor should be permitted to produce anything other than four >asterisks. F4.5 does not make sense. The standard does not make sense of F4.5, so it does not say *anything*. > Under the proposed interpretation, I have no idea what >should be expected as a result of editing under an F4.4 edit >descriptor. The same as any non-conforming program. Anything. It would be a good idea to require F4.5 to produce 4 asterisks in the next revision, sure looks like a wart to me. >------------------------- >F08/0067 C > >I agree that the program should not be standard conforming, and I agree >that the edit provided ensures that it is not. I do not agree with the >rationale given for the answer. Whether the invocation of SUB2 in SUB1 >does or does not require the shape of A depends on the argument passing >conventions used by the processor. While all or almost all existing >Fortran processors use copy-in/copy-out to pass the array argument to >SUB2, the Fortran standard does not require a conforming processor to >use copy-in/copy-out. Other argument passing conventions exist that do >not require making a copy in this case. Those conventions do not >require the shape or size of A to be known. Yes, but no-one uses such a convention. (Non-polymorphic assumed-size arrays get passed with "stride" information, are you serious?) I mean really, one could argue that assumed-size arrays can be used everywhere because you never need to know the shape, you only need to know the stride and the location of the last element. Cheers, -- ................................Malcolm Cohen, Nihon NAG, Tokyo.