From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Mon Oct 6 03:07:05 2014 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 4774A358245; Mon, 6 Oct 2014 03:07:04 +0200 (CEST) Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 360 seconds by postgrey-1.34 at www5.open-std.org; Mon, 06 Oct 2014 03:07:01 CEST Received: from nag-j.co.jp (nag-j.co.jp [111.68.142.10]) by www.open-std.org (Postfix) with ESMTP id B37F8356698 for ; Mon, 6 Oct 2014 03:06:59 +0200 (CEST) Received: from Rs (p4001-ipbf2109funabasi.chiba.ocn.ne.jp [114.148.179.1]) (authenticated bits=0) by nag-j.co.jp (8.14.5/8.14.5) with ESMTP id s9610vHE041726 for ; Mon, 6 Oct 2014 10:00:59 +0900 (JST) (envelope-from malcolm@nag-j.co.jp) Message-ID: <5DEBA364301B485180FBE8A434C4E18F@Rs> From: "Malcolm Cohen" To: "WG5" Subject: RE: (j3.2006) (SC22WG5.5332) J3 Fortran interp letter ballot #31revised - due 6-Oct-2014 Date: Mon, 6 Oct 2014 10:00:50 +0900 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 interpretations are being balloted: > >Yes No Number Title > >-Y- --- F08/0108 ultimate components and coarrays >-C- --- F08/0109 LOCK_TYPE and unlimited polymorphic >-Y- --- F08/0112 STAT= and ERRMSG= in ALLOCATE and DEALLOCATE >-Y- --- F08/0113 Specifiers in image control statements >--- -N- F08/0114 Can LOCK_TYPE components have the POINTER attribute? COMMENT for F08/0109: Bill Long writes: "The example Q3 has a variable, C, of type LOCK_TYPE that is not a coarray. This violates C1302. Answer A3 is wrong." No, it cannot violate C1302 because that is a syntax constraint. Only things that are statically detectable static properties of the program source text can be syntax constraints. That means that "type" in C1302 can only mean "declared type". C is CLASS(*) so has no declared type and therefore cannot violate C1302. C1302 ought to be fixed to say "declared type" explicitly, to avoid this confusion; [399:17] 13.8.2.16 LOCK_TYPE, C1302 "variable of type LOCK TYPE" -> "variable with declared type LOCK_TYPE". Bill continues: "For the same reason the example Q4 is defective and answer A4 is wrong. " For the same reason, there is nothing wrong with Q4. >The example code in Q5 is also defective, although could be repaired by >changing the declaration of X to > > TYPE(LOCK_TYPE),SAVE :: X[*] > >That seems to be sufficient to make answer A5 acceptable. X should certainly be explicitly made a coarray, but giving it SAVE seems unnecessary (this might be a main program or module, or might be a subprogram with a global SAVE, or X might be a dummy argument). I guess it doesn't hurt though (other than looking a bit strange to have X saved but C not, so if we're going to SAVE one we should SAVE the other). NO VOTE on F08/0114: This is just the wrong decision. People use pointers for all kinds of reasons, e.g. switching between two different structures, emulating optionality, etc. We allow pointers to be followed cross-image from a coarray, which means that pointers with a potential subobject of type LOCK_TYPE would indeed be useful in such scenarios. We should not add this new restriction; rather, we should remove the misguided "style preference" that is currently badly expressed by C1302. Cheers, -- ............................Malcolm (typhoon) Cohen.