From owner-sc22wg5@open-std.org Mon Dec 6 17:19:49 2010 Return-Path: X-Original-To: sc22wg5-dom8 Delivered-To: sc22wg5-dom8@www2.open-std.org Received: by www2.open-std.org (Postfix, from userid 521) id 45E7BC3BA1C; Mon, 6 Dec 2010 17:19:49 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from exprod6og115.obsmtp.com (exprod6og115.obsmtp.com [64.18.1.35]) by www2.open-std.org (Postfix) with ESMTP id 5BAE0C178E4 for ; Mon, 6 Dec 2010 17:19:46 +0100 (CET) Received: from source ([136.162.34.13]) (using TLSv1) by exprod6ob115.postini.com ([64.18.5.12]) with SMTP ID DSNKTP0NISUPpAv8sTSUckqhKTIxIyuc1gDs@postini.com; Mon, 06 Dec 2010 08:19:48 PST Received: from fortran.us.cray.com (fortran.us.cray.com [172.31.19.200]) by stplmr01.us.cray.com (8.14.3/8.13.8/hubv2-LastChangedRevision: 12441) with ESMTP id oB6GJikc020664; Mon, 6 Dec 2010 10:19:44 -0600 Message-ID: <4CFD0D53.8030501@cray.com> Date: Mon, 06 Dec 2010 10:20:35 -0600 From: Bill Long Reply-To: longb@cray.com Organization: Cray Inc. User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: fortran standards email list for J3 Cc: sc22wg5 Subject: Re: (j3.2006) (SC22WG5.4370) [ukfortran] WG5 informal ballot re Interop. TR References: <20101108175805.5B97EC178E5@www2.open-std.org> <20101206103130.1AE8AC178E3@www2.open-std.org> <20101206134148.834A7C178E4@www2.open-std.org> In-Reply-To: <20101206134148.834A7C178E4@www2.open-std.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-sc22wg5@open-std.org Precedence: bulk On 12/6/10 7:41 AM, Aleksandar Donev wrote: > >> A reasonable alternative would be to >> forbid passing TYPE(*) actuals to TYPE(*) dummies. > This is too drastic. We want to disallow TYPE(*) assumed-shape or > explicit-shape dummies (that is, ones that do not carry a descriptor) to I assume you meant assumed-size, since assumed-size and explicit-shape are the non-descriptor modes. However, one of the original desires of the MPI users was to have type(*),dimension(*) map to a void * dummy parameter and have only the address passed. I think this would be an often used form. > be passed as actuals for TYPE(*) dummies. That way, we ensure that type > information is always present. One can still write wrappers in Fortran > that have TYPE(*) dummies, but they will always be assumed rank. C > routines on the other hand can avoid descriptors, but can also rely on > having type information. > > Does this seem acceptable? > >> If we go for the "forbid" route, I hope >> that we can pass CLASS(*) actuals to TYPE(*) dummies - and that if this >> ends up in a C descriptor that the descriptor fields "type" (if we keep >> that) and "elem_size" (and "length" if we get that) are set >> appropriately. In fact I think we can do that anyway as the TR stands. > Yes, CLASS(*) or in fact any polymorphic thingo that already carries a > hidden type descriptor could be allowed as an actual argument > corresponding to a TYPE(*) dummy. But we need to decide this and put it > in writing in the TR. If you are looking at Fortran calling C, then allowing CLASS(*) dummies could be doable - in practice the type will always by a struct. We would still want to limit type parameters and type-bound procedures. However, if it is a C function calling Fortran with such an interface, reconstructing all of the CLASS infrastructure on the Fortran side from the information in the C descriptor might be problematic. There is no information about the struct's components in the descriptor. Cheers, Bill -- Bill Long longb@cray.com Fortran Technical Support & voice: 651-605-9024 Bioinformatics Software Development fax: 651-605-9142 Cray Inc./Cray Plaza, Suite 210/380 Jackson St./St. Paul, MN 55101