From delves@nasoftware.co.uk Mon Apr 30 13:00:57 2001 Received: from finch-post-11.mail.demon.net (finch-post-11.mail.demon.net [194.217.242.39]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id NAA46225 for ; Mon, 30 Apr 2001 13:00:56 +0200 (CEST) (envelope-from delves@nasoftware.co.uk) Received: from nasoftwr.demon.co.uk ([158.152.18.126] helo=micra.nasoftware) by finch-post-11.mail.demon.net with esmtp (Exim 2.12 #1) id 14uBQS-000Asn-0B; Mon, 30 Apr 2001 11:01:08 +0000 Received: from rover.nasoftware (IDENT:root@rover [10.9.200.53]) by micra.nasoftware (8.9.3/8.9.3) with ESMTP id LAA20279; Mon, 30 Apr 2001 11:19:11 +0100 Received: from localhost (delves@localhost) by rover.nasoftware (8.9.3/8.9.3) with ESMTP id MAA22288; Mon, 30 Apr 2001 12:19:10 +0100 Date: Mon, 30 Apr 2001 12:19:10 +0100 (BST) From: Mike Delves X-Sender: delves@rover.nasoftware To: John Reid cc: SC22WG5@dkuug.dk Subject: Re: (SC22WG5.2052) Revised draft response for interp. 31 In-Reply-To: <200104300943.LAA45746@dkuug.dk> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Dear John, I must support your response 2: the program is valid. Reason: Your draft response 2 makes a perfectly good case for this interpretation. And the program is unambiguous with such an interpretation. As a matter of principle we should not put unnecessary restrictions on the standard; to label the program invalid would invent an unneccessary restriction. Mike On Mon, 30 Apr 2001, John Reid wrote: > WG5, > Here is a revised draft response for interp. 31. Comments, > please, before I send this to J3. > > John Reid. > > > J3/01-xxx > > Date: 30 April 2001 > To: J3 > From: John Reid > Subject: Interpretation 31 (Association of pointer function result with > INTENT(OUT) dummy argument) > > Interpretation 31 is not a new interpretation. It failed its J3 ballot, > with 5 NO votes against 10 YES votes and one YES with comments. The > present response and the ballot comments (00-329) and are appended for > your convenience. > > I sent earlier drafts of this paper to the WG5 list for comments and > would like thank those that helped me get to this version, specially > Kurt, Van, Henry, and Malcolm. > > The basic problem is to decide whether a pointer function reference > with a valid target can be associated with a nonpointer dummy argument > that has intent(out) or a nonpointer dummy argument that is redefined. > That is, whether a pointer function reference is treated as an > expression in this context. > > The standard is ambiguous, as the question makes clear. It is my view > now that an edit to the standard is needed. > > The old draft said: The program does not conform to the Standard. > 12.4.1.1 [201:19-21] requires the actual argument to be definable and a > function result is not definable. For example, it is not permitted on > the left-hand side of an assignment statement, since it is not a > variable. > > I have tried the example code on the following compilers: Nag, SUN, > Epc, IBM, Compaq, Fujitsu, Salford, NASoftware. All but NASoftware > reject it with a clear message. This is consistent with the old > draft reply. Note that a majority voted YES on this. > > An alternative view is that the program conforms to the Standard > because the dummy argument is associated with the target of the actual > argument (see [200:30-32], quoted below). > > This paper provides drafts for both views, each with edits. > > .................................................. > > NUMBER: 000031 > TITLE: Association of pointer function result with INTENT(OUT) dummy > argument > KEYWORDS: Pointer association, dummy argument association, intent > attribute > DEFECT TYPE: Erratum > STATUS: J3 consideration in progress > > QUESTION: Consider the following program. > > PROGRAM P > INTEGER, TARGET :: T > > CALL SUB(FPTR()) > CONTAINS > FUNCTION FPTR() > INTEGER, POINTER :: FPTR > > FPTR => T > END FUNCTION FPTR > SUBROUTINE SUB(IO) > INTEGER, INTENT(OUT) :: IO > > IO = 17 > END SUBROUTINE SUB > END PROGRAM P > > According to 12.4.1 [200:30-32], > > "If a dummy argument is not a pointer and the corresponding > actual argument is a pointer, the actual argument shall be > currently associated with a target and the dummy argument > becomes argument associated with that target." > > According to 12.4.1 [201:19-21], > > "If a dummy argument has INTENT(OUT) or INTENT(INOUT), the actual > argument shall be definable." > > According to 5.1.2.3 [53:29-31], > > "The INTENT(OUT) attribute specifies that. . . any actual > argument that becomes associated with such a dummy argument > shall be definable." > > The definition of "definable" supplied in Annex A (the term does not > appear to be defined in normative text) is: > > "A variable is <> if its value may be changed by the > appearance of its or on the left of an > ." > > According to this definition, "definable" is a property of variables > only. In the example above, the actual argument is not a variable. > However, the actual argument is pointer associated with an object > that is definable. The text cited from 5.1.2.3 refers to the > "actual argument that becomes associated with the dummy argument", > but the first piece of text cited from 12.4.1 makes it clear that > when the actual argument is a pointer, it is the target with which > it is associated that becomes argument associated with the dummy > argument, and not the actual argument itself. > > Was it the intent of the committee that this program should not be > standard-conforming? > > ANSWER: > > The program does not conform to the Standard. 12.4.1.1 > [201:19-21] requires the actual argument to be definable and a > function result is not definable. For example, it is not permitted > on the left-hand side of an assignment statement, since it is not a > variable. > > The edits add additional text to make this clear. > > EDITS: > > In subclause 5.1.2.3, on line 3 of the paragraph that starts 'The > INTENT(OUT)' [53:31], add 'a variable that is' before 'definable'. > > In subclause 5.1.2.3, on line 3 of the paragraph that starts 'The > INTENT(INOUT)' [53:36], add 'a variable that is' before 'definable'. > > In subclause 5.1.2.3, add at the end of the last paragraph [53:38] 'The > dummy argument is not definable unless the actual argument is a > variable that is definable.'. > > In subclause 12.4.1.1, on line 20 of page 201 [201:20], add 'a variable > that is' before 'definable'. > > > ....................................................................... > > Alternative response > > ANSWER: > > It was intended that this program be standard conforming. The dummy > argument is associated with the target of the actual argument, as the > text from [200:30-32] quoted above states. In this case, the actual > argument has a valid target and the target is definable. > > The edit adds additional text to make this clear. > > EDIT: > > On page 200, subclause 12.4.1.1, at the end of the paragraph that > starts 'If the dummy argument is not a pointer' [200:32], change > 'target.' to 'target; references elsewhere in this standard to "the > actual argument associated with the dummy argument" are references to > the target'. > ....................................................................... > > SUBMITTED BY: Henry Zongaro > HISTORY: 98-177 m146 Submitted > WG5/N1414 Draft answer > 00-260 m154 Passed by J3 meeting > 00-329 m155 Failed J3 letter ballot > > .................................................... > > Old draft response > > ANSWER: The program does not conform to the Standard. 12.4.1.1 > [201:19-21] requires the actual argument to be definable and a > function result is not definable. For example, it is not permitted > on the left-hand side of an assignment statement, since it is not a > variable. > > EDIT: None. > > .................................................... > > Ballot comments > > > RichB's NO vote on 000031 > > See IBM's comments. > > Malcolm's YES comment on 000031 > > I disagree with the other comments that the dummy > argument is argument-associated with something that is > not an actual argument. The dummy argument is > associated with the (value of) the actual argument > expression. > > Craig's NO vote on 000031 > > I agree with Van's comments. > > Kurt's NO vote on 000031 > > I agree with Van. The pointer that is the function > result is not definable, but the target identified by > that pointer (in this case, T) _is_ definable. In the > example given, the dummy argument is associated with the > target, not the pointer. > > [The prohibition against a function reference appearing > on the left hand side of an assignment statement is > syntactic in nature and has no bearing on this semantic > question.] > > Van's NO vote on 000031 > > I don't know the intent of the committee, but my > experience in reading the standard is that the area of > argument association of pointers is murky. It is my > preference that a non-pointer dummy argument is > considered to be associated with a definable actual > argument if the actual argument is a pointer that is > associated with a definable target. The glossary entry > for "definable" is not normative, and, like Henry, I > could not find a normative definition for it. I prefer > not to depend on non-normative text to resolve an > interpretation. Henry's arguments concerning the > relation between the passages he cites from 5.1.2.3 and > 12.4.1 convince me that the example he provides should > be standard-conforming. If the dummy argument had the > pointer attribute, I would accept a conclusion that its > pointer association status could not be changed, because > in that case, the actual argument would be a function > result. > > Henry's NO vote on 000031 > > We are inclined to agree with Van Snyder on this > question. It is clear that the standard treats > specially pointers that appear as actual arguments when > the associated dummy is not a pointer: the dummy > becomes argument associated with the target of the > pointer, not with the actual argument itself. We agree > the actual argument is not definable, but that seems > irrelevant because the entity that is argument > associated with the target is not the actual argument in > this case. > > It seems far more likely that the drafters of the > standard failed to take into account the case of a > pointer actual argument that corresponds to a nonpointer > dummy argument when they required that the "actual > argument shall be definable" in [201:19-21] and > [53:29-31]. > > In fact, the text cited at 5.1.2.3 [53:29-31] is > particularly troublesome. To repeat, it states that: > > The INTENT(OUT) attribute specifies that. . . any > actual argument that becomes associated with such a > dummy argument shall be definable. > > But in the case of a pointer actual argument that > corresponds to a nonpointer dummy, there is no actual > argument associated with the dummy. The target of the > pointer is associated with the dummy, but the target > is not the actual argument. > > We also feel that a normative definition of the term > "definable" is required. > -- Mike Delves delves@nasoftware.co.uk N.A. Software Ltd Tel: +44 151 709 4738 62 Roscoe St, Liverpool Fax: +44 151 709 5645 Merseyside L1 9DW UK http://www.nasoftware.co.uk