J3/07-xxx To: J3 From: /interp/Stan Whitlock Subj: Results of the J3 interp letter ballot #14 Date: 29-Oct-2007 Here are the results of J3 letter ballot #14 on Fortran interpretations that officially closed 8-Oct-2007. The ballot is in J3 paper 07-279 for meeting #182. If I have transcribed a vote or a comment incorrectly, please let me know. J3 rep F03 F03 F03 F03 F03 F03 F03 F03 F03 92 93 94 95 97 98 99 100 101 Dick Hendrickson C C Y Y C C N C N Michael Ingrassia C C Y Y Y Y Y Y Y Shivarama Kokrady Y Y Y Y Y Y Y Y Y Bill Long Y Y Y Y C C C C N Jeanne Martin Y Y Y Y Y Y Y Y Y Dan Nagle Y Y Y Y Y Y Y Y Y Craig Rasmussen no ballot received Van Snyder Y Y Y Y Y Y N Y C Matthijs van Waveren no ballot received Stan Whitlock C C Y Y C C N N N Jim Xia Y C Y Y Y C N Y C 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: Y = passed C = passed as amended N = needs further consideration F03 F03 F03 F03 F03 F03 F03 F03 F03 92 93 94 95 97 98 99 100 101 C C Y Y C C N N C The interps marked "C" pass with some minor fixes, as noted below. The interps marked "N" will be reconsidered at J3 meeting #182 by the /interp committee who will decide if the status becomes "withdraw for more work", "passed as amended", or "passed as printed". The edited interps in their final form (except for the J3 number for this paper) for F03/0092, F03/0093, F03/0097, F03/0098, F03/0101 are attached for use at meeting #182. /Stan ********************************************************************** F03/0092 Procedure characteristics and unlimited polymorphic Dick Hendrickson's YES comment on F03/0092: I agree with Michael Ingrassia's comment Michael Ingrassia's YES comment on F03/0092: Doesn't procedure (foo) proc_tgt need to be procedure (foo), target :: proc_tgt according to [84:21-22] ? Stan Whitlock's YES comment on F03/0092: I agree with Michael's comment Conclusion on F03/0092: Passed J3 letter ballot #14 with Michael's change ---------------------------------------------------------------------- F03/0093 Allocatable array on intrinsic assignment with scalar expr Dick Hendrickson's YES comment on F03/0093: I agree with Michael Ingrassia's comment Michael Ingrassia's YES comment on F03/0093: The "Note to J3" should be removed. Stan Whitlock's YES comment on F03/0093: I agree with Michael's comment Jim Xia's YES comment on F03/0093: In the first edit, the second half of the sentence could be improved to say that shall be an array of the same rank as . Conclusion on F03/0093: Passed J3 letter ballot #14 with Michael's change ---------------------------------------------------------------------- F03/0094 Final subroutine and VALUE attribute Conclusion on F03/0094: Passed J3 letter ballot #14 ---------------------------------------------------------------------- F03/0095 Bounds remapped pointer assignment and ASSOCIATED Conclusion on F03/0095: Passed J3 letter ballot #14 ---------------------------------------------------------------------- F03/0097 Blanks as separators in NAMELIST input Dick Hendrickson's YES comment on F03/0097: I agree with Bill Long's comment Bill Long's YES comment for F03/0097: (a) Fix a typo in question 1. In the following question change the first "in" to "it". 1) Was in intended that blanks be allowed as separators in Namelist Input? (b) Wording changes in the questions would clarify the issue. - At the beginning of the following paragraph, add "Page 243:12 says that the name-value subsequences are separated by value separators." Page 243:5 says that namelist value separators are the same as list directed value separators. - At the beginning of question 2, add "Page 245:29-30 says that a name-value subsequence is separated from the ! in a comment by a value separator." 2) Is there a similar problem with namelist comments as in this fragment? I = 3 ! this is a namelist comment (c) Rewrite the answer to put the main subject first. Change the edit for [243:5] to put namelist first (as is the case in 04-007), so that the full edit is: "A value separator for namelist formatting is a value separator for list-directed formatting (10.9), or one or more contiguous blanks between a nonblank value and the following object designator or "!" comment initiator." (d) As a separate, but related issue, the text at [243:7-13] details the form of namelist input, but does not make any mention of comments. Is this a omission? If so, could it be fixed as part of this interp? Stan Whitlock's YES comment on F03/0097: I agree with Bill's comment Conclusion on F03/0097: Passed J3 letter ballot #14 with Bill's changes (a), (b), and (c) As to Bill's comment (d), the new definition of "value separator" in the edit covers comments when applied to that term in [243:12] . No change is needed. ---------------------------------------------------------------------- F03/0098 Does allocate with source= define subcomponents? Dick Hendrickson's YES comment on F03/0098: I agree with Bill Long and Jim Xia's comments Bill Long's YES comment for F03/0098: The answer is fine. In the following statement of the question, "allocate STATEMENT" should be "ALLOCATE statement". Bullet 11 on 422 says "Successful execution of an allocate STATEMENT ... causes the subcomponent to become undefined." Stan Whitlock's YES comment on F03/0098: I agree with Bill and Jim's comments Jim Xia's YES comment on F03/0098: The subclause numbers are wrong in edit 2 and 3: [421:27-28] 16.5.6, ... should be [421:27-28] 16.5.5, ... [421:28+] 16.5.6, ... should be [421:28+] 16.5.5, ... Conclusion on F03/0098: Passed J3 letter ballot #14 with Bill and Jim's changes ---------------------------------------------------------------------- F03/0099 Clause 16 does not account for volatile variable Dick Hendrickson's NO vote on F03/0099: We need to consider Van Snyder, Bill Long, and Jim Xia's comments Bill Long's YES comment for F03/0099: 1) Should the edit at [113:21+] really be at [113:12+]? It would make sense to put the special cases related to attributes together. 2) The edit at [415:27] in in the section about pointer association status, not about the definition status of the pointer's target. That seems to be covered by the later edits. Incorporating Van's proposed changes, I'd propose: "The association status of a pointer object with the VOLATILE attribute may be changed by means not specified by the program. In addition, its array bounds or deferred type parameters may change. If it is polymorphic, its dynamic type may change." Van Snyder's NO vote on F03/0099: An object doesn't have to be polymorphic in order to have changeable deferred length type parameters. The edit for [415:27] ought to be [415:27] Add a new paragraph at the end of 16.4.2.1.4 "When a pointer object with the VOLATILE attribute is changed by a means not specified by the program it may become defined or undefined. In addition, its array bounds, association status and deferred type parameters may change. If it is polymorphic, its dynamic type may change." Stan Whitlock's NO vote on F03/0099: No - Van, Bill, and Jim all make good points - this needs more work Jim Xia's NO vote on F03/0099: I agree partially with Van's No vote. The type parameter of a non- polymorphic entity that can be changed by means other than the program itself must be deferred. In addition, the deferred type parameter does not require the entity to be polymorphic. In the case of a polymorphic entity with VOLATILE, however, there is a possibility that the dynamic type of the entity may require type parameters in addition to those specified in the type declaration itself. Any of these additional type parameters may change due to either change of the dynamic type or change in entity's association status. This is not covered in Van's edit. So I suggest an edit as follows (it may need wordsmithery) [415:27] Add a new paragraph at the end of 16.4.2.1.4 "When a pointer object with the VOLATILE attribute is changed by a means not specified by the program it may become defined or undefined. In addition, its array bounds, association status and deferred type parameters may change. If it is polymorphic, its dynamic type and any additional type parameters not specified in its declaration may also change." Conclusion on F03/0099: Failed J3 letter ballot #14 - the above comments need to be resolved ---------------------------------------------------------------------- F03/0100 Error in field width for special cases of signed INFINITY output Dick Hendrickson's YES comment on F03/0100: I agree with Bill Long's comment Bill Long's YES comment for F03/0100: The proposed edit is unclear as to what the "otherwise" covers. A possible rewrite: [228:36-37] Replace the sentence beginning 'If is less than 3..." with "If is less than 3 + , the field is filled with asterisks; otherwise, if is less than 8 + , the field contains the sign, if present, followed by 'Inf'. The value of is 1 if a sign is produced and 0 otherwise." Stan Whitlock's NO vote on F03/0100: No - I agree with Bill that the edit needs fixing but I don't like his proposal - this needs more work Conclusion on F03/0100: Failed J3 letter ballot #14 - the edit needs to be reworded ---------------------------------------------------------------------- F03/0101 Is UDDTIO output suitable for namelist and list-directed input Dick Hendrickson's NO vote on F03/00101: I agree with Bill Long's comment Bill Long's NO comment for F03/0101: (a) Typos in the question. In this sentence of the question: Is it intended that output produced by used defined derived type routines conform to these rules? replace "used defined" with "user-defined". (b) Typos/editing problems in the answer. In the ANSWER, replace "un-delimited" with "undelimited", and "nor" with "or". (c) Typos in the edits. In each edit, replace "used-defined" with "user-defined". (d) Defects in the edits. The two edits are each self-contradictory. The first says that the form of output for list-directed output need not be compatible with the form of list-directed output. (In both cases, for the type in question, accomplished with a UDDTIO routine.) Similarly for the second edit. The paragraph being edited starts by saying that the form of output is that required for input with exceptions. This is just one of the exceptions. In particular, the UDDTIO read_formatted routine, if one is provided, need not be able to correctly process the output generated by the write_formatted routine for the same type. If there is no read_formatted routine then the default formatted input processing for the type need not be compatible with the output generated by the write_formatted routine. It is up to the programmer to get this right if needed. If that's what was meant here, then both edits could be fixed by deleting the "or output" at the end of each edit. Or do we mean to say that the form of the output from a UDDTIO routine may vary from one variable to the next, for example, by generating field widths based on calls to a random number generator? If this is what was intended, then more explanation is needed. Or was the intention to say that the form of output may differ between the cases where there is a UDDTIO routine and not? If this is what was intended, then changing "or output" to "or output that would have occurred if the type did not specify user-defined derived type formatted output". In any case, some repair to the edit is needed. Van Snyder's YES comment on F03/0101: In the last line of the answer, "nor" should be "or". Stan Whitlock's NO vote on F03/0101: No - I agree with Bill's comment Jim Xia's YES comment on F03/0101: I agree with Bill's comments (a), (b) and (c) Conclusion on F03/0101: Passed J3 letter ballot #14 with Bill's comments (a), (b), and (c) plus the conclusion in (d) paragraph 2: "both edits could be fixed by deleting the "or output" at the end of each edit ---------------------------------------------------------------------- ---------------------------------------------------------------------- NUMBER: F03/0092 TITLE: Procedure characteristics and unlimited polymorphic KEYWORDS: Procedure, unlimited polymorphic DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider abstract interface function foo (x) class(*) x class(*), pointer :: foo end function end interface procedure (foo), pointer :: proc_ptr procedure (foo), target :: proc_tgt proc_ptr => proc_tgt According to the rules of procedure pointer assignment at [144:39-41], proc_ptr and proc_tgt are required to have the same interface characteristics. However because an unlimited polymorphic entity is not considered to have a declared type, the rules for characteristics of dummy data objects [256:26-32] and characteristics of function results [257:2-8] are not applicable. In addition, rules at [145:5-6] require that proc_ptr and proc_tgt have the same function return type. This also does not apply to unlimited polymorphic data. Is the example intended to be standard-conforming? ANSWER: Yes, the example was intended to be standard-conforming. An edit is provided to clarify this. The characteristics however are adequately defined. FOO, and thus both PROC_PTR and PROC_TGT have no type, but are polymorphic; this precisely characterises an unlimited polymorphic entity. Only the requirement of type matching in 7.4.2.2 is incorrect. EDITS to 04-007: [145:5] After "the same type" insert " or both be unlimited polymorphic". SUBMITTED BY: Jim Xia HISTORY: 07-247 m181 F03/0092 Submitted 07-247r1 m181 Passed by J3 meeting 07-xxx m182 Passed as changed by J3 letter ballot #14 ---------------------------------------------------------------------- NUMBER: F03/0093 TITLE: Allocatable array on intrinsic assignment with scalar expr KEYWORDS: allocatable array, intrinsic assignment DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Consider CHARACTER(:), ALLOCATABLE :: str(:) ALLOCATE (CHARACTER(1) :: str(0:9)) str = 'reallocate?' According to the third paragraph of 7.4.1.3, the variable STR should be deallocated on this assignment because it has a deferred length type parameter different from the ('reallocate?'); it should then be allocated with its length type parameter the same as that of the and with the shape and bounds of . But the STR cannot be allocated with the shape and bounds of the since it is a scalar. The standard, however, provides a possible interpretation for the shape of two paragraphs later where it says "If is a scalar and is an array, the is treated as if it were an array of the same shape as with every element of the array equal to the scalar value of ." Q(1). Should the variable STR be reallocated in this case? Q(2). If so, what are the values of its length type parameter, shape and bounds? ANSWER: (1) Yes, STR should be reallocated - that is the purpose of the combination of ALLOCATABLE and deferred type parameters. If the user does not wish for automatic reallocation he can use "str(:) = 'do not reallocate'" instead. (2) The length parameter of str after the assignment is 11 (the value returned by LEN('reallocate?')). The shape and bounds should be unchanged. An edit is provided to clarify this. Note that the standard does not forbid, but does not specify semantics for, str = 'oops' when STR is an unallocated array with a deferred length parameter. An edit is supplied to make it clear that this is not allowed. Note also that this applies to parameterized derived types with deferred type parameters. EDITS: [139:22-] Insert new sentence at beginning of paragraph "If is an unallocated allocatable array, shall be an array of the same rank as ." [139:25] Change "corresponding type parameters of ," to "corresponding type parameter of ." [139:25] Before ", with the shape of " Insert ". If is an array and is scalar it is allocated with the same bounds as before, otherwise it is allocated". SUBMITTED BY: Jim Xia HISTORY: 07-248 m181 F03/0093 Submitted 07-248r2 m181 Passed by J3 meeting 07-xxx m182 Passed as changed by J3 letter ballot #14 ---------------------------------------------------------------------- NUMBER: F03/0097 TITLE: Blanks as separators in NAMELIST input KEYWORDS: Namelist input, blanks, separators DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: 1) Was it intended that blanks be allowed as separators in Namelist Input? Consider a namelist input fragment: I = 3 J = 4 Page 243:12 says that the name-value subsequences are separated by value separators. Page 243:5 says that namelist value separators are the same as list directed value separators. Page 239:7 says those value separators are "...blanks between values" and then defines what the values are. The "J" above isn't a value, so the blanks aren't separators and the fragment is illegal for namelist input 2) Is there a similar problem with namelist comments as in this fragment? I = 3 ! this is a namelist comment Page 245:29-30 says that a name-value subsequence is separated from the ! in a comment by a value separator. ANSWER: 1) Yes, it was intended to allow blanks as separators for namelist input. Edits are supplied to correct the wording in the standard. 2) Yes, there is a similar problem with comments. The fragment is intended to be legal. The edits correct the error. EDITS: [243:5] Replace the paragraph by "A value separator for namelist formatting is a value separator for list-directed formatting (10.9), or one or more contiguous blanks between a nonblank value and the following object designator or "!" comment initiator." SUBMITTED BY: Dick Hendrickson HISTORY: 07-267 m181 F03/0097 Submitted 07-267r2 m181 Passed by J3 meeting 07-xxx m182 Passed as changed by J3 letter ballot #14 ---------------------------------------------------------------------- NUMBER: F03/0098 TITLE: Does allocate with source= define subcomponents? KEYWORDS: allocate, source, define DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: Was it intended that an allocate with a source= clause define subcomponents? Bullet 11 on 422 says "Successful execution of an ALLOCATE statement ...causes the subcomponent to become undefined." ANSWER: An Allocate with a SOURCE= specifier was intended to define subcomponents. In fact, none of the lists in clause 16 account for a SOURCE= specifier. Edits are supplied to clarify this. EDITS: [113:21] At the end of the last sentence in 6.3.1.1 insert "unless they are defined by a SOURCE= specifier" [421:27-28] 16.5.5, list item 19, modify by adding after "Allocation of an object", "except by an ALLOCATE statement with a SOURCE= specifier". [421:28+] 16.5.5, insert new list item after (19) "(19a) Successful execution of an ALLOCATE statement with a SOURCE= specifier causes a subobject of the allocated object to become defined if the corresponding subobject of the SOURCE= expression is defined." [422:41] 16.5.6, list item (11) insert "with no SOURCE= specifier" after "ALLOCATE statement" [422:43+] 16.5.6, add a new list item after (11), "(11a) Successful execution of an ALLOCATE statement with a SOURCE= specifier causes a subobject of the allocated object to become undefined if the corresponding subobject of the SOURCE= expression is undefined." SUBMITTED BY: Dick Hendrickson HISTORY: 07-268 m181 F03/0098 Submitted 07-268r2 m181 Passed by J3 meeting 07-xxx m182 Passed as changed by J3 letter ballot #14 ---------------------------------------------------------------------- NUMBER: F03/0101 TITLE: Is UDDTIO output suitable for namelist and list-directed input KEYWORDS:UDDTIO, list-directed I/O, namelist I/O DEFECT TYPE: Erratum STATUS: Passed by J3 letter ballot QUESTION: The first paragraph of 10.9.2 says that the form of the values produced by list-directed output is the same as that required for input. It also says values are separated blanks or commas, etc. The first paragraph of 10.10.2 has similar words for namelist output. It also requires that the variable name be produced in upper case and that the output consist of name-value pairs. Is it intended that output produced by user-defined derived type routines conform to these rules? ANSWER: No, it was not intended to constrain the user-derived type output values. There should be an exception similar to the one for adjacent undelimited character values. User derived type output fields do not need to be readable by either namelist or list-directed input. EDITS: [241:5] Add at the end of the paragraph "The form of the output produced by a user-defined derived type output routine invoked during list-directed output is specified by the invoked routine. It need not be compatible with list-directed input." [246:4] After "and logical values" add ", and output produced by user-defined derived type output" [246:7] Add at the end of the paragraph "The form of the output produced by a user-defined derived type output routine invoked during namelist output is specified by the invoked routine. It need not be compatible with namelist input." SUBMITTED BY: Dick Hendrickson HISTORY: 07-275 m181 F03/0101 Submitted 07-275r2 m181 Passed by J3 meeting 07-xxx m182 Passed as changed by J3 letter ballot #14 ----------------------------------------------------------------------