J3/01-275 Date: 26-Jul-2001 To: J3 Members From: /interp/Stan Whitlock Subj: Results of the F95 interp letter ballot #5 Here are the results of J3 letter ballot #5 on Fortran 95 interpretations that closed on 20-Jul-2001. If I have transcribed a vote or a comment incorrectly, please let me know. J3 rep 31 94 F90 F90 F90 F90 F90 190 191 196 204 205 Rich Bleikamp Y Y Y Y Y Y Y Malcolm Cohen Y Y Y Y Y Y Y Craig Dedo N Y Y Y N Y Y Dick Hendrickson N Y Y Y Y Y Y Kurt Hirchert N Y Y Y Y C Y Bill Long Y Y Y Y Y Y Y Jeanne Martin Y Y Y Y Y Y Y Larry Meadows Y Y Y Y Y Y Y Dan Nagle Y Y Y Y Y Y Y Mallory North Y Y Y Y Y Y Y Mike Ross Y Y Y Y Y Y Y Van Snyder N Y Y Y Y Y Y Matthijs van Waveren Y Y Y Y C Y Y Stan Whitlock Y Y Y Y Y Y Y Richard Maine C C informational John Reid Y Y Y Y N Y Y infromational where Y means "yes" C "yes with comment" N "no with comment" The comments are attached below in the same order as the table above. John Reid and Rich Maine's e-mail comments are included, even though neither has a vote. The summary of DRAFT results is as follows: P = passed C = passed as amended F = further consideration 31 94 F90 F90 F90 F90 F90 190 191 196 204 205 F P P P P P P The interps marked "P" can be considered by WG5 at John Reid's convenience. The interps marked "F" will be reconsidered at or before J3 meeting #158 by the /interp committee who will decide if the status becomes "withdraw for more work", "passed as amended", or "passed as printed". /Stan ********************************************************************** Number Title 000031 Association of pointer function result with INTENT(OUT) dummy argument Dedo's NO vote on 31: I agree with Van's "NO" vote and his reasons. I believe that dereferencing a pointer argument in this case is the rule that we should adopt. Hendrickson's NO vote on 31: I go back and forth on this one. I now agree with Van's comments. There is no clear statement in the standard about what should happen in this case. I think dereferencing the pointer argument is the way to go. Hirchert's NO vote on 31: 1. Even if one accepts the logic of this answer, the Edits are defective. The term "definable" is not defined in normative text. Adding qualifying words and another reference to definable does make those statements clear when the fundamental term remains undefined. [Procedural note: this is new argument!] 2. It is questionable whether the definition of "definable" in annex A is precise, but even if it were a normative definition, the reasoning here is flawed. The cited text from [200:30-32] indicates that IO ultimately is associated with the target of FPTR(), that is, T. T _is_ a variable and definable by this definition. A helpful analogy might be to consider an actual argument of the form ARRAY(INT_FUN()). In that case, INT_FUN() is an expression, but it is mere used to identify the actual argument (a specific element of ARRAY). In the case being interpreted, FPTR() is an expression that is being used to identify the actual argument (T). 3. The implementation implications of the proposed interpretation are appalling. Although it disallows associating the result of a pointer function with a non-pointer dummy argument of intent OUT or INOUT, it does allow such associations if the intent is unspecified or IN, and in the latter cases effectively requires the processor to a. allocate new storage the size of the target, b. copy the value of the target to that storage, c. supply the address of that new storage as the argument of the procedure, and then d. deallocate that storage after the procedure has completed. In contrast, the interpretation I favor would be valid for all possible intents and would involve only taking the address information in the descriptor returned by the pointer function and placing it in the argument list of the procedure, with no additional memory management or value copying. I suggest that my alternative interpretation is useful, makes the simplest notation efficient to implement, and allows the expression the expression of the more expensive semantics if it is what the programmer truly needs. The proposed interpretation makes the simplest notation expensive to implement, and provides no direct notation to express the useful, efficient semantics. (One must result to the indirect approach of copying the descriptor into a pointer variable and using it, hoping the compiler will be clever enough to optimize away this unnecessary work.) [Procedural note: I believe this argument, although previously made orally, is new to our written letter ballots.] 4. [I originally intended to include to some material that I hoped would clarify the committee's original intentions in this regard. However, I realize that those original intentions are clearly reflected in the text from [200:30-32], so I omit that material.] Snyder's NO vote on 31: The text at 200:30-32 makes it clear that the target of a pointer actual argument is the entity that becomes argument associated with a nonpointer dummy argument; there are no passages that contradict this in the case that the actual argument is a function result. There are no exceptions in the standard to the general rule that the target of a pointer is definable if the target of the pointer is definable. The only place where such a contradiction might appear is in the discussion of the INTENT attribute for pointer dummy arguments, and this makes it clear that it applies to the association status, not the target. The citation in the answer of a requirement at 201:19-21 that the actual argument shall be definable if the dummy argument has INTENT(IN) or INTENT(OUT) is therefore irrelevant to the question. It cannot logically be used to support the answer. The contradiction introduced by this interpretation doesn't make any program clearer, more efficient, or more likely to be correct. In fact, one might argue the opposite. Indeed, introducing a pointer variable puts a heavier burden on the optimizer. The primary effect of introducting this contradiction will be to perpetuate the tradition of imposing needless restrictions and irregularities that serve only to confuse people who are trying to learn, teach or use the language. Maine's COMMENT on 31: I agree with Van's position and reasons on interp 31. F90/000196 Inaccessibility of intrinsic procedures Dedo's NO vote on F90/196: I agree with the comments of John Reid and Richard Maine. The note should be rewritten according to the recommendations of John Reid. I will change my vote to "Yes" if this change is made. van Waveren's COMMENT on F90/196: Reid mentions that the first sentence of Note 14.2 should be replaced with the DISCUSSION part of the interp. We note that the DISCUSSION text will be part of document 006, and will be available to interested parties through the J3 web site, so it does not absolutely have to be part of the standard. Maine's COMMENT on F90/196: I see merit in John Reid's comment that the discussion in interp F90/196 would make a good replacement for the first sentence on the note. It does seem a pretty well-written discussion, written in a style and length well suited to a note, and it seems at least concievable that a reader might be mislead by the existing wording in the note. I don't, however, think it necessary to add distracting verbiage to rule out all the possible things that could be in the ... to make the example incorrect. That would not help the purpose of the note. For example, I don't think a reader would be confused enough to think that the claim in the note still applied if the first ... included an END SUBROUTINE statement. Reid's NO COMMENT on F90/196: Notes are not normative and are written in a less formal way than the text of the standard, but what they say should be correct. The first sentence of NOTE 14.2 is incorrect and needs to be changed. The text now included as DISCUSSION is a suitable replacement for this sentence (see 01-221). /interp response on F90/196 based on 01-221 vs 01-221r1: Note 14.2 [276:9-10] currently starts: "An intrinsic procedure is inaccessible in a scoping unit containing another local entity of the same class and having the same name." Reid's edit would be: In section 14.1.2, NOTE 14.2, [276:9-10], change the first sentence to "Ordinarily, uses of intrinsic procedures are recognized automatically and require no explicit declaration, even if IMPLICIT NONE is in effect. However, if a scoping unit contains another local entity of the same class and having the same name as an intrinsic procedure, the automatic recognition of the intrinsic procedure is prevented, except in the case that the local entity and intrinsic procedure are both generic procedures." So it's the "except in the case that the local entity and intrinsic procedure are both generic procedures" that would make the existing text correct. F95 states 3 lines above note 14.2 [276:5-6]: "Within a scoping unit, a name that identifies a local entity of one class shall n ot be used to identify another local entity of the same class, except in the case of generic names (12.3.2.1)." /interp felt that enough warning existed in the text that additional verbiage was not needed in the note. CONCLUSION: A quick poll of /interp agrees that F90/196 passes as printed. F90/000204 Meaning of "same variable" description of MVBITS Hirchert's COMMENT on F90/204 I do not believe this is what we originally intended by this phrase, but it is a plausible interpretation of those words, and programmer needing the fuller functionality I believe was originally intended can still get it by putting parentheses around the FROM argument to make it an expression.