10-105 To: J3 From: Stan Whitlock Subject: Results of the J3 interp letter ballot #20 Date: 2010 January 30 Here are the results of J3 letter ballot #20 on Fortran interpretations that officially closed 18-Dec-2009. The ballot is in J3 paper 09-307 for meeting #191. If I have transcribed a vote or a comment incorrectly, please let me know. J3 rep F03 F03 F03 139 140 141 Malcolm Cohen (1) C Robert Corbett Y Y Y Bill Long C Y Y Dan Nagle Y Y Y Craig Rasmussen Y Y Y Van Snyder C Y Y Stan Whitlock Y Y Y Jim Xia C Y Y (1) Malcolm Cohen is the voting alternate for Jeanne Martin where Y means "yes" C "yes with comment" N "no with comment" The comments for each interp are attached below in the same order as the table above. The summary of DRAFT results is as follows: F03 F03 F03 139 140 141 C Y Y Y = passed C = passed as amended F = Failed J3 letter ballot I = /interp needs to confer at meeting 190 The interps marked "C" pass with some minor fixes, as noted below. The edited interps in their final form are attached and will appear in the next version 006A. No edits were aplied to F2008 09-007r3 at this time because of these interp answers. /Stan ********************************************************************** F03/0139 Functions returning procedure pointers Bill Long's YES vote Comment on F03/0139: [12:17] edit reference should be [12:16] {Agree with Van.} [280:34-35] It is not clear why the entire sentence is deleted, rather than just changing the "variable" to "entity", or just deleting "variable". After all, in 12.2.2, one of the characteristics of a function result is "whether it is a procedure pointer". [280:36] With this edit, the sentence reads "On completion of execution of the function, the value returned is that of its result." I had thought the issue with using the word "variable" is that they had a "value" and that was not appropriate for a procedure pointer. If so, then it seems this sentence is still defective. Do procedure pointers have "values"? [The two sentences that follow suggest that "value" is reserved for nonpointer results. On the other hand, [415:17] suggests the opposite.] [407:21-23] Possible alternate edits: In the first sentence, replace "result variable" with "result which may be a variable or a pointer". In the second sentence, delete "variable" twice. [430:13] raises the same question as to whether a pointer has a "value". Maybe not an issue, since at [415:17] we pretty clearly say a pointer has a "value". Malcolm Cohen's comment on Bill Long's comment on F03/0139: Bill Long wrote: > [280:34-35] It is not clear why the entire sentence is deleted, > rather than just changing the "variable" to "entity", or just > deleting "variable". After all, in 12.2.2, one of the > characteristics of a function result is "whether it is a > procedure pointer". Because it has zero information content. After correction, it reads "The characteristics of the function result are those of the [function] result." which is rather tautological. Anyway, we spell it out in tedious detail two paragraphs earlier. > [280:36] With this edit, the sentence reads "On completion of > execution of the function, the value returned is that of its > result." I had thought the issue with using the word "variable" > is that they had a "value" and that was not appropriate for a > procedure pointer. No, the issue with using the word "variable" is that ***procedure pointers are NOT variables***. Variables are data objects. Procedures are not data objects. Procedure pointers are procedures with the POINTER attribute, and therefore also not data objects, and therefore also not variables. > If so, then it seems this sentence is still defective. Do > procedure pointers have "values"? Sure, the value of a procedure pointer is its association. > [The two sentences that follow suggest that > "value" is reserved for nonpointer results. On the other hand, > [415:17] suggests the opposite.] "value" is not a defined term. One needs to understand it in the appropriate context. For components we actually describe the situation fairly rigorously (in 4.5.7), but we don't do that for non-component pointers. > [407:21-23] Possible alternate edits: > In the first sentence, replace "result variable" with "result > which may be a variable or a pointer". In the second sentence, > delete "variable" twice. I don't see why we need to give permission here. "named result entity which is either a variable or a procedure pointer" would be ok. Saying "named result entity" avoids any possible misinterpretation of the sentence as talking about the actual value of the result at some time (not that that would really make sense). > [430:13] raises the same question as to whether a pointer has a > "value". Maybe not an issue, since at [415:17] we pretty clearly > say a pointer has a "value". I don't think it's an issue. Van Snyder's YES vote Comment onF03/0139: First edit should be for [12:16]. Edit for NOTE 12.37 needs to change "variable" to "entity" twice at [281:0+2,4]. Better yet, re-word the final sentence of the note. Something like "If the function result is a variable, its final value is used subsequently in the evaluation of the expression that invoked the function. An implementation might...." This is still questionable because it's probably not a good idea to release the storage before the value is used, but that would be the subject of a different interp, and almost pointless because this is, after all, just a note. Edit for [283:25] should change to "result names identify the same entity", not "result names identify the same variable". Not really related, but this interp got me looking: [04-007:415:22+] (8) The pointer is a function result and the function is invoked. Something similar is needed in 09-007r3:16.5.2.5. Insert "The" before "" in C809a at [160:17+] In the edit for [292:9+] replace "and" by "or" Jim Xia's YES vote Comment on F03/0139: In answer (1b), it says [430:13] "data object"->"data entity". Shouldn't this be changed to [430:13] "data object"->"entity"? Results of the vote on F03/0139: passed as amended: In the (1b) edits: * {Van} Change the [12:17] edit to [12:16]. * {Van} Expand the edit to Note 12.37 [280:40+]: Change "variable" to "entity" 4 times. * {Van} Change the [283:25] edit to read: Change "result variables identify the same variable" to "result names identify the same entity" and delete ", although their names need not be the same". * {Bill} Fix the [407:21-23] edit to be: [407:21-22] replace "result variable" with "named result entity which is either a variable or a procedure pointer". [407:22-23] change "variable" to "entity" twice. * {Jim} Change the [430:13] edit to be "data object" -> "entity". In the (2b) edits: * {Van} Insert "The" before "" in C809a at [160:17+]. * {Van} In the edit for [292:8+] replace "and" with "or". ---------------------------------------------------------------------- NUMBER: F03/0139 TITLE: Functions returning procedure pointers KEYWORDS: procedure pointer DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: (1) Is a function permitted to return a procedure pointer? Much of the language talks about the function result variable, but a procedure pointer is not a variable. For example, 2.2.3 says [12:16] "The VARIABLE that returns the value of a function is called the RESULT VARIABLE." (emphasis mine); which indicates that the value of a function is returned in a variable. (2) Where may a function reference that returns a procedure pointer appear? In particular, (a) as a in a SELECT TYPE or an ASSOCIATE statement; (b) within parentheses as a primary; (c) as the argument to an intrinsic inquiry function such as KIND or LEN. (3) [12:18-19] says "a subroutine may be used to change the program state by changing the values of any of the data objects accessible to the subroutine". A procedure pointer is not a data object, so is this meant to imply that a subroutine is not permitted to change the state of a procedure pointer? Similar text for functions appears in the same paragraph. ANSWER: (1b) Yes, a function is permitted to return a procedure pointer; the text calling this a variable is in error. Edits are supplied to correct these mistakes. (2b) It was intended that a function reference that returns a procedure pointer only be permitted as an argument to the ASSOCIATED and NULL intrinsic functions and in places where an ordinary procedure name would be acceptable. Parentheses around a pointer act to dereference the pointer and return a copy of the value: this action is inapplicable to procedures. Thus the answers to the specific sub-questions are No, No, and No again. Clarifying edits are provided. (3) No, this implication should not be drawn. A clarifying edit is provided. EDITS for (1b): [12:16] Change "The variable that ... the result variable" to "The entity that ... the function result". [75:13] After "function result" delete "variable". [93:16] After "of the result" delete "variable". [115:7] After "function result" delete "variable". [280:18-19] After "name of the result" delete "variable". [280:22] After "name of the result" delete "variable". [280:31] After "name of the result" delete "variable". [280:33] After "not specified, the" Change "result variable" to "name of the result". [280:34] After "references to the result" delete "variable". [280:34-35] Delete "The characteristics ... the result variable.". [280:36] After "that of its result" change "variable" to "entity". [280:36] Change "is a pointer" to "is a data pointer", [280:37] After "shape of the result" delete "variable". [280:38] Change "result variable" to "function result". [280:39] After "with the result" delete "variable". [280:40+] In Note 12.37, Change "variable" to "entity" four times. [283:20] After "name of its result" delete "variable". [283:22] Change "result variable" to "result name". [283:25] Change "result variables identify the same variable" to "result names identify the same entity" and delete ", although their names need not be the same". [287:17] After "The result" delete "variable". [400:7] "result variable is a scalar"->"result is a scalar object". [407:8] After "identify the result" delete "variable". [407:12-13] After "identify the result" delete "variable". [407:21-22] "result variable" -> "named result entity which is either a variable or a procedure pointer". [407:22-23] Change "variable" to "entity" twice. [415:40] Change "result variables" to "function results that are variables". [417:18] Change "of the result" to "of the result entities if they are variables". [423:14] "The result variable of a function" ->"The result of a function that returns a data object". [430:13] "data object"->"entity". [434:10] Delete whole line. EDITS for (2b). [117:27+] Insert new constraint "C703 (R701) The shall not be a function reference that returns a procedure pointer." [160:17+] Insert new constraint "C809a (R819) The shall not be a function reference that returns a procedure pointer." [292:8+] Insert new paragraph "An argument to an intrinsic procedure other than ASSOCIATED, NULL, or PRESENT shall be a data object." EDITS for (3). [12:19] After "data objects" insert "or procedure pointers". SUBMITTED BY: Malcolm Cohen HISTORY: 09-295 m190 F03/0139 submitted - Passed by J3 meeting: B answers passed 10-xxx m191 Passed as amended by J3 letter ballot #20 09-307 ---------------------------------------------------------------------- NUMBER: F03/0140 TITLE: Type of nested construct entities. KEYWORDS: ASSOCIATE, DATA, FORALL, SELECT TYPE DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the example: PROGRAM bad REAL x INTEGER i,y(10) ASSOCIATE (x=>i) ! B DATA (y(x),x=1,10)/10*1/ ! A DO x=1,10 ! B y(x) = SQRT(y(x)) ! B END DO ! B FORALL(x=1:10) y(x) = y(x)**2 ! C END ASSOCIATE ! B x = SUM(y) END PROGRAM Is this program conforming? That is: Within the ASSOCIATE construct, is X of type INTEGER? It certainly is in the statements marked with "! B". But according to 16.3 paragraph 2 [409:18-20], in the statement marked "! A", X has the type it has in the scoping unit, which would have to be REAL. And according to 16.3 paragraph 3 [409:25-27], in the statement marked "! C", X has the type it has in the scoping unit, which would have to be REAL. If X is type REAL for DATA and FORALL, the program would not be conforming, but it would be if X were of type INTEGER. ANSWER: Within the scope of a construct entity name, it was intended that a data-implied-do index or a FORALL index name should have the type and type parameters of the construct entity name. Edits are provided to clarify this. EDITS: [409:19] 16.3 Statement and construct entities, para 2, sentence 2, Before "scoping unit" insert "innermost executable construct or". {Makes a difference for DATA in ASSOCIATE and SELECT TYPE only.} [409:26] 16.3, paragraph 3, sentence 2, Before "scoping unit" insert "innermost executable construct or". {Makes a difference for FORALL in ASSOCIATE and SELECT TYPE only.} SUBMITTED BY: Malcolm Cohen HISTORY: 09-301 m190 F03/0140 submitted - Passed by J3 meeting 10-xxx m191 Passed by J3 letter ballot #20 09-307 ---------------------------------------------------------------------- NUMBER: F03/0141 TITLE: More than one specific interface for a procedure KEYWORDS: Specific interface DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider the example: module A contains subroutine S ( X ) real :: X end subroutine S end module A module B use A, only: T => S end module B module C use A, only: U => S end module C program P use B ! Access the procedure name T use C ! Access the procedure name U ! T and U are different names for the same procedure. end program P Is this program conforming? The procedure S defined in the module A has two explicit specific interfaces in program P. The sixth paragraph after constraint C1211 in subclause 12.3.2.1 says "A procedure shall not have more than one explicit specific interface in a given scoping unit." ANSWER: It was intended that this program be conforming. An edit is provided to correct this. EDITS: [260:1 last sentence of sixth paragraph after constraint C1211 in subclause 12.3.2.1] Insert "name" after "procedure". SUBMITTED BY: Van Snyder HISTORY: 09-304 m190 F03/0141 submitted - Passed by J3 meeting 10-xxx m191 Passed by J3 letter ballot #20 09-307 ----------------------------------------------------------------------