From owner-sc22wg5@open-std.org Thu Oct 14 04:38:21 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 94D53C3BA13; Thu, 14 Oct 2010 04:38:21 +0200 (CET DST) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org X-Greylist: delayed 1556 seconds by postgrey-1.18 at www2.open-std.org; Thu, 14 Oct 2010 04:38:20 CEST Received: from ns.nag-j.co.jp (218-42-159-107.cust.bit-drive.ne.jp [218.42.159.107]) by www2.open-std.org (Postfix) with ESMTP id 89625C3BA03 for ; Thu, 14 Oct 2010 04:38:20 +0200 (CET DST) Received: from [127.0.0.1] (helo=www.nag-j.co.jp ident=www-data) by ns.nag-j.co.jp with smtp (Exim 4.50) id 1P6DIk-0007vw-1T; Thu, 14 Oct 2010 11:12:14 +0900 Date: Thu, 14 Oct 2010 11:12:14 +0900(JST) Message-ID: <20101014111214.9753.malcolm@nag-j.co.jp> In-Reply-To: <20101013225723.591E6C3BA03@www2.open-std.org> References: <20101013225723.591E6C3BA03@www2.open-std.org> From: malcolm@nag-j.co.jp To: sc22wg5@open-std.org Subject: Re: [ukfortran] (SC22WG5.4340) 10-208r1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: Mailer Sender: owner-sc22wg5@open-std.org Precedence: bulk Reinhold bader wrote: > I do not understand Then I'm sorry but we have spelled it out twice now - once in 2008, and now in 2010. 10-208r1 says: If the dynamic type of object "o_foo" were "badfoo", the call to the type-bound procedure cannot be resolved without enquiring the type of o_foo%badcomponent on image 2 (because it needs to know ************************ how much to copy, and how); this type is not necessarily the ************************* same type as that of o_foo%badcomponent on image 1. (emphasis added). The whole point of the changes in 2008 (which I personally was not in favour of, but that is a horse of a different colour) was to remove any possibility of inquiring the type of a polymorphic object on another image. You say > (2) copy object from remote image to invoking image That's the problem. You can't do that. You can't do that because it has a polymorphic allocatable subcomponent. On another image. Copying the object involves copying the allocatable subcomponent. Which requires knowing what *its* type is - not just how big it is itself but also whether *it* has any further allocatable subcomponents. That requires inquiring the type of that subcomponent, and that subcomponent only exists on the remote image, not the local image. The entire point of the changes we made in 2008, in the paper you referenced, was so that we would NOT need to inquire the type of a polymorphic object on another image. Maybe you think not being able to inquire the type of a remote object is a horrible restriction, and if so I'd agree with that, but that is unfortunately what we agreed to. Or if you think not being able to inquire the type of a remote object is fine, well then there is no choice but to accept the consequences - which are that the compiler too cannot inquire the type. And in the situation inquired about in 10-208, the compiler would need to do exactly that. Cheers, -- ...................Malcolm Cohen.