From owner-sc22wg5@open-std.org Tue Dec 9 15:05:57 2008 Return-Path: X-Original-To: sc22wg5-dom7 Delivered-To: sc22wg5-dom7@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id 28625CA343D; Tue, 9 Dec 2008 15:05:57 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from ppsw-0.csi.cam.ac.uk (ppsw-0.csi.cam.ac.uk [131.111.8.130]) by www2.open-std.org (Postfix) with ESMTP id 56AD1CA3439 for ; Tue, 9 Dec 2008 15:05:50 +0100 (CET) X-Cam-AntiVirus: no malware found X-Cam-SpamDetails: not scanned X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/ Received: from hermes-1.csi.cam.ac.uk ([131.111.8.51]:46982) by ppsw-0.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.150]:25) with esmtpa (EXTERNAL:nmm1) id 1LA3Di-0007yM-0G (Exim 4.70) for sc22wg5@open-std.org (return-path ); Tue, 09 Dec 2008 14:05:50 +0000 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1LA3Di-0007bd-2I (Exim 4.67) for sc22wg5@open-std.org (return-path ); Tue, 09 Dec 2008 14:05:50 +0000 Received: from [83.67.89.123] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.1); 09 Dec 2008 14:05:50 +0000 Date: 09 Dec 2008 14:05:50 +0000 From: "N.M. Maclaren" To: sc22wg5@open-std.org Subject: Re: [ukfortran] (SC22WG5.3788) (j3.2006) N1761, TYPE(*), BIND(C) and arrays Message-ID: In-Reply-To: <20081209134507.F156EC178E5@www2.open-std.org> References: <20081127193527.EF00DC178D9@www2.open-std.org> <20081202130345.82E16C178E1@www2.open-std.org> <20081209122438.AE57DCA3439@www2.open-std.org> <20081209134507.F156EC178E5@www2.open-std.org> X-Mailer: Prayer v1.3.1 Mime-Version: 1.0 Content-Type: text/plain; format=flowed; charset=ISO-8859-1 Sender: owner-sc22wg5@open-std.org Precedence: bulk On Dec 9 2008, Reinhold Bader wrote: > >It appears to me that if non-interoperable arguments are to be allowed, >it will be necessary to include interoperability among the >characteristics of the dummy arguments if a clean, extensible >design is favored. Yes, indeed, though there are many ways of doing it. And, with the approach of N1761, there aren't just interoperable and non-interoperable but several intermediate states. >This would probably also mesh nicely with the concept of creating >mapped (as opposed to matching) interfaces in case at least one >of the arguments is non-interoperable. And it would cover the >problematic case of a scalar non-interoperable entity as well. Careful design would be needed, and I should be happy to work with people on that. >Of course, for the TR many limitations can be imposed on what kinds >of non-interoperable entities are allowed. In particular I agree that >additional restrictions will be needed for TYPE(*) dummies in BIND(C) >interfaces to prevent accidents from happening to the poor C programs >who are being served monsters and non-monsters in turn to the same >interface, within the same program. Indeed. But they haven't been. I don't think N1761 is ready to be considered as a draft TR. Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: nmm1@cam.ac.uk Tel.: +44 1223 334761 Fax: +44 1223 334679