From owner-sc22wg5@dkuug.dk Sun Jul 27 23:51:47 2003 Received: (from majordom@localhost) by dkuug.dk (8.12.8p1/8.9.2) id h6RLplt5046135 for sc22wg5-domo; Sun, 27 Jul 2003 23:51:47 +0200 (CEST) (envelope-from owner-sc22wg5@dkuug.dk) X-Authentication-Warning: ptah.dkuug.dk: majordom set sender to owner-sc22wg5@dkuug.dk using -f Received: from Mail.Math.Princeton.EDU (mail.math.Princeton.EDU [128.112.18.14]) by dkuug.dk (8.12.8p1/8.9.2) with ESMTP id h6RLpdEc046128 for ; Sun, 27 Jul 2003 23:51:42 +0200 (CEST) (envelope-from adonev@Math.Princeton.EDU) Received: from atom.Princeton.EDU (atom.Princeton.EDU [128.112.143.9]) (authenticated bits=0) by Mail.Math.Princeton.EDU (8.12.9/8.12.9) with ESMTP id h6RLpXvk020470 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Sun, 27 Jul 2003 17:51:34 -0400 From: Aleksandar Donev Organization: Princeton University To: WG5 Subject: Re: (SC22WG5.2901) Nagging Doubts Date: Sun, 27 Jul 2003 17:51:33 -0400 User-Agent: KMail/1.5 References: <200307272128.h6RLSv3F046000@dkuug.dk> In-Reply-To: <200307272128.h6RLSv3F046000@dkuug.dk> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200307271751.33267.adonev@math.princeton.edu> Sender: owner-sc22wg5@dkuug.dk Precedence: bulk Hello, Here are some comments to Kurt's complaints (most of which I have heard before in one form or another in various discussions): > ==================================== > Nagging Doubt II: Type Compatibility > ==================================== I'll leave this one to Malcolm... > ======================================================= > Nagging Doubt III: The "Value" of a Derived-Type Object > ======================================================= > CALL SUB(X,(X)) > How is a processor supposed to preserve this > part of the value for the duration of SUB's execution? It cannot, so maybe the text that requires that should be modified instead. Something like the value at the *beginning* of the execution... > I suggest that for derived-types, we can give rules for > enumerating the possible representations that type could have, > but that enumeration is not the same thing as an enumeration of > the values of that type. If you look at my paper which made this "clarification of VALUE", you will see that I also agree that "value of" is not something the standard can really define because it depends on what the derived type actually represents (i.e. the abstraction), but it is not possible to fix this in Fortran now (or maybe ever). The edits merely try to patch the very *inadequate* definition of value of in the previous draft which did not at all say anything about the distinction between ordinary, pointer and allocatable components. The edits were not meant to provide a great new definition of "value of", as I do not know how to do that. At least implementors can implement the present text. And the user who does your CALL SUB(X,(X)) and expects miracles will simply be reminded not to expect miracles from computers :-( Best, Aleksandar -- NOTE change of primary e-mail to adonev@math.princeton.edu __________________________________ Aleksandar Donev Complex Materials Theory Group (http://cherrypit.princeton.edu/) Princeton Materials Institute & Program in Applied and Computational Mathematics @ Princeton University Address: 419 Bowen Hall, 70 Prospect Avenue Princeton University Princeton, NJ 08540-5211 E-mail: adonev@math.princeton.edu WWW: http://atom.princeton.edu/donev Phone: (609) 258-2775 Fax: (609) 258-1177 __________________________________