From owner-sc22wg5+sc22wg5-dom8=www.open-std.org@open-std.org Tue Mar 13 09:55:52 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 31DE89DB112; Tue, 13 Mar 2012 09:55:52 +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 F1BD9356685 for ; Tue, 13 Mar 2012 09:55:50 +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 1S7NVG-0001P3-0m for sc22wg5@open-std.org; Tue, 13 Mar 2012 17:54:46 +0900 Message-ID: From: "Malcolm Cohen" To: "WG5" References: <20120312205547.B38759DB112@www.open-std.org> In-Reply-To: <20120312205547.B38759DB112@www.open-std.org> Subject: Re: [ukfortran] (SC22WG5.4630) Comment on N1904 cont'd Date: Tue, 13 Mar 2012 17:55:47 +0900 Organization: =?utf-8?B?5pel5pysTkFH?= MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original 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 BTW, please don't send to both WG5 and J3 ... the J3 list gets the WG5 list already. >It appears to me to be a good idea to enforce interoperable >type and type parameters for non-assumed-type dummy entities. Absolutely. >With respect to John's point about C1255 I am not sure I agree; >the constraint points to paragraphs where interoperability of >variables is defined, and I think it is there that the extensions >to the concept of interoperability for variables should be placed; I disagree. These are not interoperable in the old sense of having the same representation, but in the new sense of having an automatic conversion between the Fortran entity and the C entity. (Indeed, this was explicit in older drafts of the TS.) Although it is certainly *possible* to mangle interoperable to include the interconvertible, that is actually more work than just fixing C1255. Substantially more work. We've already got text for procedure interoperability that handles them defined as now (viz outside the interoperable umbrella), and that text would be completely broken. I feel reasonably confident that we can fix C1255 reliably and without doing damage to the rest of the standard. I am also reasonably confident that changing tack and "fixing" 15.3.5/6 will reliably be broken and cause further damage elsewhere in the standard. Cheers, -- ................................Malcolm Cohen, Nihon NAG, Tokyo.