From owner-sc22wg5@open-std.org  Mon Dec  8 22:39:05 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 01E94C178E1; Mon,  8 Dec 2008 22:39:05 +0100 (CET)
X-Original-To: sc22wg5@open-std.org
Delivered-To: sc22wg5@open-std.org
Received: from mailrelay2.lrz-muenchen.de (mailrelay2.lrz-muenchen.de [129.187.254.102])
	by www2.open-std.org (Postfix) with ESMTP id 33ED9C178D6
	for <sc22wg5@open-std.org>; Mon,  8 Dec 2008 22:39:03 +0100 (CET)
Received: from [129.187.48.215] ([129.187.48.215] [129.187.48.215]) by mailout.lrz-muenchen.de with ESMTP for sc22wg5@open-std.org; Mon, 8 Dec 2008 22:38:40 +0100
Message-Id: <493D93E0.8070603@lrz.de>
Date: Mon, 08 Dec 2008 22:38:40 +0100
From: Reinhold Bader <Reinhold.Bader@lrz.de>
User-Agent: Thunderbird 2.0.0.18 (Windows/20081105)
MIME-Version: 1.0
Cc: "WG5, " <sc22wg5@open-std.org>
Subject: Re: (j3.2006) (SC22WG5.3763)  Response on the TR29113 draft N1761
References: <20081207203535.92039C178D6@www2.open-std.org> <20081208183121.F21E4C178E4@www2.open-std.org>
In-Reply-To: <20081208183121.F21E4C178E4@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

Aleksandar Donev schrieb:
> Hi,
>
> I am still processing Reinhold's proposals, but this I have thought 
> about already:
>
>   
>> Issue 2 - polymorphism of assumed-type entity:
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Since no changes to the definition of C_LOC() have been introduced,
>> and this function is used to cast an object of TYPE(*) to a usable
>> type, the text beginning in line 92 of N1761 should be replaced by
>>     
> I am not sure I understand. If the dummy is TYPE(*), and the actual is 
> polymorphic, then the assumed type of the dummy becomes the dynamic 
> type of the actual. It is no longer polymorphic once you are inside the 
> procedure. 
That is how the TR in its present form wants it to be, and I intuitively 
followed the otherwise valid
rule that a CLASS(x) actual cannot ever be matched do a TYPE(x) dummy in 
formulating my
issue.
And the implications of allowing polymorphism here still make me squirm 
because of
unintended side effects like having a TYPE(*), VOLATILE dummy and 
coaxing the external
mechanism into changing the type  of this object from outside :-)


> So what is the problem with doing C_LOC on it?
>
>   
>> "In the association of actual and dummy arguments, an assumed-type
>>  dummy argument is type and kind compatible with a non-polymorphic
>>  actual data argument of any type."
>>     
> I think there be some restriction that the type should be interoperable 
> if the procedure is BIND(C). But I am not sure it can be made to work. 
> It definitely requires more work.
>
> Best,
> Aleks
>
> _______________________________________________
> J3 mailing list
> J3@j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3
>   

