From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Mon Oct 31 01:33:53 2016 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 0095F3582C8; Mon, 31 Oct 2016 01:33:52 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from nag-j.co.jp (bvdeuz19.secure.ne.jp [180.222.80.19]) by www.open-std.org (Postfix) with SMTP id B27103569C7 for ; Mon, 31 Oct 2016 01:33:48 +0100 (CET) Received: (qmail 51097 invoked from network); 31 Oct 2016 09:33:45 +0900 Received: from unknown (HELO Maru10) (218.42.159.105) by 0 with SMTP; 31 Oct 2016 09:33:45 +0900 Message-ID: From: "Cohen Malcolm" To: "WG5" References: <20161028134238.1EADD3582C8@www.open-std.org> <20161028195918.EF3F93582C8@www.open-std.org> In-Reply-To: <20161028195918.EF3F93582C8@www.open-std.org> Subject: Re: [ukfortran] (SC22WG5.5801) Straw ballot on four small technical changes Date: Mon, 31 Oct 2016 09:33:50 +0900 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 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Sender: owner-sc22wg5@open-std.org Precedence: bulk >I shall be very happy to change my NO votes if someone points out >that I have made mistakes. The primary mistake is thinking that we are voting on the edits to the draft. We are not. We are voting on the technical changes, at the feature level. I'm sure the technical nitpicks are welcome input for further improvements, but they are not what we are voting on now. >06-280r2 > >Point 1: >I had to read this several times to be quite sure of what it was saying. >I suggest adding an extra question and answer: Lacking a working time machine, it is not possible to add anything to the papers that will be passed by J3 meeting 211 which finished several weeks ago. Since this would have no effect on the standard... >06-285r2 > >I think that we have two meanings of deallocate in the standard. That would be mistaken. > But, >whether we do or not, the last sentence of [84:32 7.5.6.3p2] is >baffling And what is more baffling is that this sentence which is not part of the feature being described in the paper, and does not affect in any way that feature, is being given as a reason not to have the feature. The sentence that is allegedly baffling appears only in the paper because an earlier sentence in the paragraph has a minor editorial change, so we give the "making the whole paragraph read" result. It literally has no effect on the feature being added (clarification of ordering when intrinsic assignment affects an allocatable finalizable subobject) because that case is excluded from consideration by the preceding sentence "... except ...". The paper perhaps should have included an example, but one can just go back to F08/0013 (Corrigendum 1, see N1907 for the interp) and imagine that instead of the whole variable being allocatable, it is an allocatable component. That's it. I.e. where the interp has Type(t1),Allocatable :: x(:) x = ap1 ! (*1) imagine it has Type wrapper Type(t1),Allocatable :: x(:) End Type Type(wrapper) w w = wrapper(ap1) ! (*1) etc. Armed with this understanding, one should be able to decide whether we ought to clarify that the effects on the hypothetical W%X are the same as the effects on the hypothetical X, by voting YES. Or by voting NO, that we should keep programs that have such assignments non-conforming. (BTW the sentence being suggested for deletion, which has nothing to do with this feature, is important so is not going to be deleted any time soon. I decline to debate that sentence at this time however, as that would turn a red herring into a red halibut.) >06-277r1 > >C_SIZEOF is not permitted for an assumed-size array [486:24 18.2.3.7p3], >but we permit assumed-size arrays to be actual arguments corresponding >to assumed-rank dummies. This inconsistency needs resolving. That is a very fair comment for further improvements, but the question on the table is whether we should do the feature, not whether we should get the wording right (the answer to the latter being "yes of course!"). > One change would be: > > [486:24] 18.2.3.7p3 delete "that is not an assumed-size array". This is not addressing any inconsistency; we decided (a long time ago) that it was perfectly fine to continue to prohibit assumed-size arrays from appearing in contexts which required their shape, while allowing assumed-rank arrays to appear n such contexts, and with well-defined semantics if associated with an assumed-size array. See for example the LBOUND, UBOUND, SHAPE and SIZE intrinsics. > [486:31] 18.2.3.7p6 append "if the argument is an assumed-size > array or is an assumed-rank object that corresponds to an > assumed-size actual argument, the value returned is -1." However this suggestion would break the identity C_SIZEOF(X) = SIZE(X)*STORAGE_SIZE(X)/STORAGE_SIZE(C_CHAR_'X') We went to the trouble to specify SIZE and SHAPE that are consistent for this case, IMO it is better maintain that consistency in this case... (or just prohibit C_SIZEOF when assumed-rank X is associated with an assumed-size array)... ...***IF*** we do the feature. You need to vote YES or NO regardless of how the technical nits are picked here. Cheers, -- ........................Malcolm Cohen, Nihon NAG, Tokyo.