From owner-sc22wg5@open-std.org Sat Feb 13 15:15:11 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 796BCC178E1; Sat, 13 Feb 2010 15:15:11 +0100 (CET) X-Original-To: sc22wg5@open-std.org Delivered-To: sc22wg5@open-std.org Received: from mailrelay1.lrz-muenchen.de (mailrelay1.lrz-muenchen.de [129.187.254.106]) by www2.open-std.org (Postfix) with ESMTP id ACFD5C178DA for ; Sat, 13 Feb 2010 15:15:09 +0100 (CET) Received: from [129.187.48.234] ([129.187.48.234] [129.187.48.234]) by mailout.lrz-muenchen.de with ESMTP for sc22wg5@open-std.org; Sat, 13 Feb 2010 15:14:38 +0100 Message-Id: <4B76B3CE.5040603@lrz.de> Date: Sat, 13 Feb 2010 15:14:38 +0100 From: Reinhold Bader User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: WG5 Subject: Re: Urgent: letter ballot on interps Content-Type: multipart/mixed; boundary="------------080206050308060802050807" Sender: owner-sc22wg5@open-std.org Precedence: bulk This is a multi-part message in MIME format. --------------080206050308060802050807 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Attached please find my reply. --------------080206050308060802050807 Content-Type: text/plain; name="Answer_N1806.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Answer_N1806.txt" Yes No Number Title -Y- --- F95/0098 Are dummy functions returning assumed-length character legal? -Y- --- F03/0022 Coexistence of IEEE and non-IEEE kinds -Y- --- F03/0024 DEALLOCATE and array pointers -Y- --- F03/0034 IEEE_LOGB() --- --- F03/0039 HYPOT() -Y- --- F03/0063 Procedure pointers in BLOCK DATA program units -Y- --- F03/0071 Subroutine/function ambiguity in generics --- --- F03/0078 IEEE_SUPPORT_DATATYPE vs. mathematical equivalence --- -N- F03/0090 Polymorphic array constructors -C- --- F03/0112 Attributes allowed for dummy arguments in defined assignments --- --- F03/0119 Elemental procedures and deferred length character components -Y- --- F03/0122 When do objects of sequence derived type have the same type? -Y- --- F03/0125 Definitions of EXTENDS_TYPE_OF and SAME_TYPE_AS -Y- --- F03/0126 References to VOLATILE variables in pure procedures -Y- --- F03/0127 Duration of procedure execution --- --- F03/0129 C_LOC of character substrings -Y- --- F03/0130 Elemental specific intrinsic procedure characteristics -Y- --- F03/0131 SAVE attribute and EQUIVALENCE -Y- --- F03/0132 Unformatted i/o and private components -Y- --- F03/0133 Is unlimited polymorphic allowed in COMMON? -Y- --- F03/0134 Implicit typing of procedure pointers -Y- --- F03/0135 Interaction between RESULT, recursion, and host generic -Y- --- F03/0136 Are subroutines distinguishable from arrays? -Y- --- F03/0137 Dummy procedure type compatibility --- -N- F03/0138 External as -Y- --- F03/0139 Functions returning procedure pointers --- --- F03/0140 Type of nested construct entities --- -N- F03/0141 More than one specific interface for a procedure Comments: F03/0090: ~~~~~~~~~ The answer to question (2) appears to be overly restrictive; If the first two edits are adopted and the restriction is added that the dynamic type of all element values must be the same, question (3) would also be satisfactorily answered. F03/0112: ~~~~~~~~~ I do not understand the answers provided in the interp text. In detail: "Preventing the first argument from having the POINTER attribute violates F90." If this statement refers to the Fortran 90 or Fortran 95 standard, it appears to be simply untrue. In these standards, the code from Q2. would be rejected since it was not allowed to specify INTENT for entities with the POINTER attribute. In the Fortran 2003 context - as indicated in the answer - no problem occurs with specifying these attributes. Indeed, producing polymorphic entities is impossible to do without using these attributes. Perhaps this should be mentioned in the answer rather than referencing past and therefore irrelevant standards. "Preventing the second argument from having the ALLOCATABLE attribute would introduce a prohibition not specified by TR 15581, and might therefore be viewed as an incompatibility that ought to be announced in subclause 1.5." Considering it is not possible to use such an interface as a specific in defined assignment as indicated by the suggested NOTE, it is unclear to me what purpose this sentence has. Perhaps it can be simply omitted? Furthermore, the interp's argumentation would surely also apply to defined operations. Should NOTE 12.9 not be correspondingly changed or removed? F03/0138: ~~~~~~~~~ The answer to (2) does not provide a rationale. Do I understand correctly that it is the "CALL X" statement in example1 which establishes X to be known as an external procedure? If so, why is having "X" on the right hand side of a procedure pointer assignment considered insufficient for the same purpose? F03/0141: ~~~~~~~~~ While I agree with the answer, I think the proposed edit is more confusing than clarifying (a procedure name does not have an interface). I'd suggest adding suitable text to 11.2.1 instead, perhaps something like [252:24+] The interface of any local identifier of a procedure is that of the procedure, except that its name is replaced by the local identifiers' name. --------------080206050308060802050807--