From j.l.schonfelder@liverpool.ac.uk Mon Apr 30 20:06:29 2001 Received: from mailhub2.liv.ac.uk (mailhub2.liv.ac.uk [138.253.100.95]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id UAA48380 for ; Mon, 30 Apr 2001 20:06:28 +0200 (CEST) (envelope-from j.l.schonfelder@liverpool.ac.uk) Received: from pcmail2.liv.ac.uk ([138.253.31.161]) by mailhub2.liv.ac.uk with esmtp (Exim 3.22 #1) id 14uI4F-0005AQ-00; Mon, 30 Apr 2001 19:06:39 +0100 Received: from [138.253.134.59] (helo=liv-dialup.liv) by pcmail2.liv.ac.uk with smtp (Exim 3.16 #2) id 14uI4C-0007Vu-00; Mon, 30 Apr 2001 19:06:37 +0100 From: Lawrie Schonfelder Reply-To: j.l.schonfelder@liverpool.ac.uk To: Mike Delves Cc: John Reid , SC22WG5@dkuug.dk Subject: (SC22WG5.2053) Revised draft response for interp. 31 In-Reply-To: <200104301100.NAA46235@dkuug.dk> Message-ID: Date: Mon, 30 Apr 2001 19:06:49 +0100 (GMT Daylight Time) Priority: NORMAL X-Mailer: Simeon for Win32 Version 4.1.5 Build (43) X-Authentication: IMSP MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII John, my druthers on this are to agree with Mike. If there is a sensible interpretation of the user intent then we should make the sensible interpretation. Unnecessary restrictions are just that and should be avoided unless there is a VERY VERY strong argument to do otherwise. On Mon, 30 Apr 2001 12:19:10 +0100 (BST) Mike Delves wrote: > 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 > -- Lawrie Schonfelder Honorary Senior Fellow, University of Liverpool Home: 1 Marine Park, West Kirby, Wirral, UK CH48 5HN Phone: +44(151)625 6986