From owner-sc22wg5@open-std.org  Mon Dec  8 21:07:34 2008
Return-Path: <owner-sc22wg5@open-std.org>
X-Original-To: sc22wg5-dom7
Delivered-To: sc22wg5-dom7@www2.open-std.org
Received: by www2.open-std.org (Postfix, from userid 521)
	id 5E999C178DA; Mon,  8 Dec 2008 21:07:34 +0100 (CET)
X-Original-To: sc22wg5@open-std.org
Delivered-To: sc22wg5@open-std.org
Received: from mailout11.t-online.de (mailout11.t-online.de [194.25.134.85])
	by www2.open-std.org (Postfix) with ESMTP id DB20FC178D6
	for <sc22wg5@open-std.org>; Mon,  8 Dec 2008 21:07:33 +0100 (CET)
Received: from fwd08.aul.t-online.de 
	by mailout11.sul.t-online.de with smtp 
	id 1L9mOB-0007Lu-01; Mon, 08 Dec 2008 21:07:31 +0100
Received: from [192.168.2.100] (Z2C9feZcrhq+O0YfXi5iE871xrnAybNCguzb4BvTaD6hT0cAJYa3thD0deHYpTpw8i@[84.154.62.33]) by fwd08.aul.t-online.de
	with esmtp id 1L9mO1-1jiDlQ0; Mon, 8 Dec 2008 21:07:21 +0100
Message-ID: <493D7E78.5040402@lrz.de>
Date: Mon, 08 Dec 2008 21:07:20 +0100
From: bader-reinhold@t-online.de (Reinhold Bader)
Reply-To: Bader@lrz.de
User-Agent: Thunderbird 2.0.0.18 (X11/20081112)
MIME-Version: 1.0
To: fortran standards email list for J3 <j3@j3-fortran.org>
Cc: sc22wg5@open-std.org, longb@cray.com
Subject: Re: (j3.2006) (SC22WG5.3769)    Response on the TR29113 draft N1761
References: <20081207203535.92039C178D6@www2.open-std.org>	<20081208171349.2CAD1C178E4@www2.open-std.org>	<20081208184041.89C0DC178E4@www2.open-std.org> <20081208190353.C4B27C178DC@www2.open-std.org>
In-Reply-To: <20081208190353.C4B27C178DC@www2.open-std.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
X-ID: Z2C9feZcrhq+O0YfXi5iE871xrnAybNCguzb4BvTaD6hT0cAJYa3thD0deHYpTpw8i
X-TOI-MSGID: f7f861bf-eeda-46da-803b-cd2703e0b788
Sender: owner-sc22wg5@open-std.org
Precedence: bulk

Craig Rasmussen schrieb:
> On Dec 8, 2008, at 11:40 AM, Reinhold Bader wrote:
> 
>>
>> Bill Long schrieb:
>>> Reinhold Bader wrote:
>>>
>> Note that the
>>> main purpose of adding this feature was for MPI-like interfaces,  
>>> where
>>> the only objective was to pass the object to a C function and give  
>>> the
>>> function tools to correctly interpret the object.
>> Yes. Note that I'm not yet sure the MPI Forum is going to swallow  
>> this since
>> the MPI vendors apparently don't want to rewrite their whole  
>> infrastructure to use
>> descriptors ... even though it provides the technically better  
>> solution.
> 
> Since the MPI vendors will have to write wrappers for the MPI  
> functions, there is no real technical problem for them and I don't  
> think they will complain too loudly (I will ask at the MPI Forum next  
> week).  The main requirement is that existing _users code_ won't need  
> to change.  

I understand descriptors are out for these since assumed shape
actuals cannot be handed over.

> The way the TR is currently written, I think the MPI 3.0  
> Fortran interfaces won't use assumed shape dummy variables and so  
> vendors won't need to access descriptors.

Issue 4 from my comments contends that it is not possible to
fulfill the main requirement above with the current TR.

> 
> Regards,
> Craig
> 

Regards
Reinhold