From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Wed Mar 14 00:51:11 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 B93793569A1; Wed, 14 Mar 2012 00:51:11 +0100 (CET) Delivered-To: sc22wg5@open-std.org Received: from ns.nag-j.co.jp (218-42-159-107.cust.bit-drive.ne.jp [218.42.159.107]) by www.open-std.org (Postfix) with ESMTP id 16C9A35693F for ; Wed, 14 Mar 2012 00:51:09 +0100 (CET) Received: from 218-42-159-108.cust.bit-drive.ne.jp ([218.42.159.108] helo=Maru6) by ns.nag-j.co.jp with smtp (Exim 4.50) id 1S7bTj-0003Bm-6i for sc22wg5@open-std.org; Wed, 14 Mar 2012 08:50:07 +0900 Message-ID: From: "Malcolm Cohen" To: "sc22wg5" References: <20120312205547.B38759DB112@www.open-std.org><20120313085552.AED2D9DB113@www.open-std.org><20120313133844.E22BD356959@www.open-std.org><20120313170629.292739DB112@www.open-std.org> <20120313204150.507ED9DB112@www.open-std.org> In-Reply-To: <20120313204150.507ED9DB112@www.open-std.org> Subject: Re: [ukfortran] (SC22WG5.4636) (j3.2006) Issue with C1255 in Interop TS Date: Wed, 14 Mar 2012 08:51:09 +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.3538.513 X-MimeOLE: Produced By Microsoft MimeOLE V15.4.3538.513 Sender: owner-sc22wg5@open-std.org Precedence: bulk >The current para 1 of 15.3.5 is: > >"A named scalar Fortran variable is interoperable if and only if its type and >type parameters are interoperable, it is not a coarray, it has neither the >ALLOCATABLE nor the POINTER attribute, and if it is of type character its >length is not assumed or declared by an expression that is not a constant >expression." > >Among things that would appear to qualify as "interoperable" variables >according to this: > >1) an assumed-type dummy argument associated with an interoperable effective >argument. No. An assumed-type dummy argument has no declared type so cannot satisfy the requirements. (Also see final comments.) >2) an assumed-shape or assumed-rank dummy argument with type and type >parameters that are interoperable. Assumed-shape dummy arguments are not scalar. There might be a problem if we think of assumed-rank variables as being scalar. Which as it stands I guess we do think of them as being "conditionally" scalar. Ugh. So can we have an elemental procedure with an assumed-rank argument? Oh dear. Maybe we should just change the definition of "scalar" to exclude assumed-rank... >Certainly the assumed-rank and assumed-shape cases come under the "new sense" >of interoperable. Assumed-type is different, but I think still not anticipated >by the current text. It is covered in precisely the same way that CLASS(*) is. No-one has been confused about that, so I see no reason for confusion now. Remember that unless clear otherwise from the context, "type" means both declared and dynamic type. It might be a harmless clarification to insert "declared" into that sentence, but I'd need to think about it more; excluding dynamic type parameters from consideration certainly looks potentially problematic, whereas leaving it as the default both declared and dynamic is definitely ok. Cheers, -- ................................Malcolm Cohen, Nihon NAG, Tokyo.