From owner-sc22wg5@open-std.org Mon Jan 5 22:53:18 2009 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 BB260CA342E; Mon, 5 Jan 2009 22:53:18 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by www2.open-std.org (Postfix) with ESMTP id D7BFDCA3429 for ; Mon, 5 Jan 2009 22:53:17 +0100 (CET) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n05LrE6c027800 for ; Mon, 5 Jan 2009 21:53:14 GMT Received: from ranma.sfbay.sun.com (ranma.SFBay.Sun.COM [129.146.84.89]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n05LrEr4050931 for ; Mon, 5 Jan 2009 13:53:14 -0800 (PST) Received: (from michaeli@localhost) by ranma.sfbay.sun.com (8.11.7p1+Sun/8.11.7) id n05LrEr01364 for sc22wg5@open-std.org; Mon, 5 Jan 2009 13:53:14 -0800 (PST) Date: Mon, 5 Jan 2009 13:53:14 -0800 (PST) From: Michael Ingrassia Message-Id: <200901052153.n05LrEr01364@ranma.sfbay.sun.com> To: sc22wg5@open-std.org Subject: Re: WG5 letter ballot 5 on technical content of N1761 X-Sun-Charset: US-ASCII Sender: owner-sc22wg5@open-std.org Precedence: bulk Although my ballot did not make the deadline, perhaps the comments are still of use so I pass them on for what they are worth. No with comments: 0) The file ISO_Fortran_binding.h does not appear to be included with N1761. I assume this is an oversight? 1) The general approach of standardizing a data structure (incompletely) seems awkward compared to the approach of standardizing the particular sorts of APIs that programmers will want (e.g. what is the rank? what is the base address? please change the base address, etc.) Standardizing a structure might make it difficult to change the structure from one compiler release to the next, as the structure is "frozen" in the ABI. 2) There is no "version" query for the structure or the ABI. If a vendor makes changes from one release to the next, does the user have any portable way of detecting differences? 3) If C descriptors and Fortran descriptors are in true correspondence, then it is hard to understand the reason for an asymmetry where the C descriptor has an fdesc field but the Fortran descriptor need not have a cdesc field or equivalent. 4) An assumed-rank variable cannot appear in many contexts. It therefore seems like too radical a syntax change for the benefit obtained. Some such syntax as %REF for passing addresses of objects might be simpler and has some actual deployment history. 5) A TR advancing interoperability of Fortran with C should make some mention of variadic functions. 6) The user model seems needlessly complex, or I am not understanding all of it. It is called a "two descriptor model" but given that the API supplies ways of synthesizing multiple descriptors to refer to the same "physical" data object, it seems that there are really any number of descriptors. The API allows "efficient" access to objects defined by descriptors, but does not permit a full calculus of descriptors (do two descriptors describe the same object?). Since some user-initiated actions like deallocation require an implementation to be able to distinguish descriptors, it's not clear that the API is complete enough.