From owner-sc22wg5@open-std.org Tue Dec 9 21:53:05 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 38BBACA343D; Tue, 9 Dec 2008 21:53:05 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from ppsw-1.csi.cam.ac.uk (ppsw-1.csi.cam.ac.uk [131.111.8.131]) by www2.open-std.org (Postfix) with ESMTP id 77915CA3439 for ; Tue, 9 Dec 2008 21:53:03 +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]:48594) by ppsw-1.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.151]:25) with esmtpa (EXTERNAL:nmm1) id 1LA9Zn-0004Wy-47 (Exim 4.70) for sc22wg5@open-std.org (return-path ); Tue, 09 Dec 2008 20:53:03 +0000 Received: from prayer by hermes-1.csi.cam.ac.uk (hermes.cam.ac.uk) with local (PRAYER:nmm1) id 1LA9Zn-0004gO-8Q (Exim 4.67) for sc22wg5@open-std.org (return-path ); Tue, 09 Dec 2008 20:53:03 +0000 Received: from [83.67.89.123] by webmail.hermes.cam.ac.uk with HTTP (Prayer-1.3.1); 09 Dec 2008 20:53:03 +0000 Date: 09 Dec 2008 20:53:03 +0000 From: "N.M. Maclaren" To: sc22wg5@open-std.org Subject: Re: [ukfortran] (SC22WG5.3800) (j3.2006) Ballot on the technical content of the TR Message-ID: In-Reply-To: <20081209185852.F3F67CA3439@www2.open-std.org> References: <20081127193527.EF00DC178D9@www2.open-std.org> <20081209182926.6302BCA343D@www2.open-std.org> <20081209185327.4208BCA3439@www2.open-std.org> <20081209185852.F3F67CA3439@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, Aleksandar Donev wrote: > >> That says WHAT it intends to do, but not WHY those facilities are not >> needed but not (say) the ability to interoperate with derived types >> containing allocatable components. >Because: > >1) No one proposed that and WG5 did not vote on it >2) It was proposed, and people thought it important, to provide C >mechanisms to call Fortran procedures with assumed-shape, pointer, and >allocatable arrays of interoperable type. WG5 voted on it "yes" >3) You were not there (I am serious). For heaven's sake, the Fortran standard is meant to be read by people who weren't there - I should not have to have been at the relevant meeting in order to understand a specification. One of the ISO guidelines (it may even be a rule) is that facilities shouldn't be added without some good reason to do so. In this context, a good reason is a USE or VENDOR requirement, and not just someone's pet hobby-horse. I don't think that there IS a good reason in this case, but should be happy to be provided with evidence to the contrary. >If you believe "the ability to interoperate with derived types >containing allocatable components" is essential that is fine, propose >it and WG5 will vote. What I believe important is that any extensions are (a) important enough to real users to justify vendors implementing them, (b) specified cleanly and precisely enough to be used reliably and portably, (c) not in conflict with existing features and (d) not designed so that they block future extensions. N1761 fails to justify (a), and fails on all of (b), (c) and (d). That is not good :-( >Perhaps your issues are mostly with assumed-rank and assumed-type >dummies? As I said right at the beginning, the first issue is that it is unclear exactly what N1761 is proposing. In particular, WHAT it is it proposing for (a) normative specification, (b) informative Notes and (c) discussion in Annexes? Without that, it is impossible to have a serious technical debate, as these extremely unproductive threads demonstrate. But, as far as I can see, the problems are mainly with the interactions, and not with the individual facilities. Even the problem with the descriptors I posted is one of an interaction between N1761's facility and the existing Fortran array facilities. >These were added to the TR mandate later, because: >1) It was seen as a major hole in interop (easy-to-use/safe interop with >void* arguments) and inclusion in the TR was thus seen as a good idea >(you can vote against it) >2) Descriptors provide a way to pass such dummies since they contain >both some type and rank information, that C can then extract and use. Heck - I have been using them for interfacing (with both Fortran and other languages) for 35+ years - you don't have to tell me THAT! That's not where the problems lie. 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