J3/00-203 Date: 24-May-2000 To: J3 Members From: Interp/Stan Whitlock Subj: Results of the F95 Interp letter ballot #1 Here are the results of J3 letter ballot #1 on Fortran 95 interpretations that closed on 19-May-2000. If I have transcribed a vote or a comment incorrectly, please let me know. J3 rep 66 67 68 69 70 71 72 76 77 79 80 82 83 84 Larry Meadows for KBierman Y Y Y Y Y Y Y Y Y Y Y Y Y Y Rich Bleikamp Y Y Y Y Y Y Y Y Y Y Y Y Y Y Malcolm Cohen/Rich Maine Y N Y Y C C Y Y Y Y C Y Y Y Craig Dedo Y Y Y Y Y Y Y Y Y Y Y Y Y Y Dick Hendrickson Y Y Y Y Y Y Y Y Y N Y Y Y Y Kurt Hirchert N Y N Y Y N Y N Y N C Y N Y Dan Nagle Y Y Y Y Y Y Y Y Y Y Y Y Y Y Mallory North Y Y Y Y Y Y Y Y Y Y Y Y Y Y Mike Ross ** no ballot received ** Jeanne Martin for BSmith Y Y Y Y Y Y Y Y Y N Y Y Y Y Van Snyder Y Y Y Y Y Y Y Y Y Y Y Y Y Y Jon Steidel C N N Y N C C C C C N C Y Y Matthijs van Waveren Y Y Y Y Y N Y Y Y Y Y Y Y Y Tony Warnock Y Y Y Y Y Y Y Y Y Y Y Y Y Y Stan Whitlock Y Y Y Y Y Y Y Y Y Y Y Y Y Y Henry Zongaro/Kelvin Li N N C C C N C N C C N C Y Y 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. The summary of results is as follows: P = passed 66 67 68 69 70 71 72 76 77 79 80 82 83 84 C = passed as amended F F F C F F C F C F F C F P F = further consideration The interps marked "F" will be reconsidered at J3 meeting #153 by the /interp committee who will decide if the status becomes "withdraw for more work", "passed as amended", or "passed as printed". /Stan ********************************************************************** Status Number Title F 000066 Errors in processing data transfer statements Kurt's comment on NO vote on 000066: The edit and answer seem to assume that errors are always detected at the point they occur. It is entirely possible that an error may occur in the middle of a record but not be detected until the end of the record (e.g., by a mismatched CRC or parity check or backspace length). In such a case, it would be quite possible that the value of IDX could be corrupt, so the data transfer to A(IDX) could have trashed something critical. Thus the sample program is not standard conforming in the presence of this kind of error on this kind of implementation. On the other hand, if the error occurs during the transfer of J and is detected at that point, treating the entire input list as undefined is overly strong in two different ways: 1) No error occurred during the transfer of IDX, so there is nothing wrong with its value. 2) The transfer to A(IDX) should never be reached, so even if IDX is undefined, it should not be considered to be referenced. The proposed edits deal with the second issue, but not the first. The proposed edits also appear to be incomplete in that they modify 9.4.4 but not the statement in 9.4.3 that _all_ input list items become undefined. [Historical aside: I raised this very point during the public review of the draft of FORTRAN 77. At the time, the nonconformance of such programs was judged not important enough to change this aspect of the language.] I also have reservations about whether the proposed change reflects what the committee wanted all along or just what the committee wants now, but since the general thrust of what it wants now is what I have wanted all along (even when I wrote that comment letter on the FORTRAN 77 public review draft), I will not object on that basis. Jon's comment on YES vote on 000066: The comment is not about the proposed answer to the interpretation request, rather it is to state that we disagree with Kurt and Henry's ballot comments. We find their proposed solutions are too implementation specific, requiring certain checks in specific order, which break existing implementations. Henry's comment on NO vote on 000066: The first comment on this item is minor, the second is more substantive, and is the reason for the NO vote. In the edit for 9.4.4, we would rather see the conditions listed than the abbreviation "end/error conditions"; that would be more consistent with existing usage, and not significantly more typing. Our recommended edit is: In clause 9.4.4, [150:32], in list item (5), change "or namelist" to "or namelist, until an error, end-of-file, or end-of-record condition occurs, or until the entire input/output list or the namelist group has been processed" The proposed edit attempts to clarify the point at which processing of an I/O list stops in the presence of an error by stating that data transfer occurs until an error is encountered. There are still cases in which the order in which things occur is unclear. In particular, is an implementation obligated always to check for error conditions prior to processing the first item in the or ? The use of the word "until" seems to imply that. In the following example, is a processor required to check for and detect end or error conditions prior to processing the first I/O item in the READ statement? If so, this program would be required to print the value "1". If not, the edit doesn't specify things as clearly as we believe it was intended to. PROGRAM P INTEGER A(1) OPEN(UNIT=99, FORM='UNFORMATTED', ACCESS='SEQUENTIAL', + STATUS='REPLACE', ACTION='READWRITE') END FILE(UNIT=99) REWIND(UNIT=99) READ(UNIT=99,END=100) A(IF()) 100 PRINT *, IF() END PROGRAM FUNCTION IF() INTEGER :: COUNT = 1 IF = COUNT COUNT = COUNT + 1 END FUNCTION IF F 000067 Writing zeros Richard Maine's comment on NO vote on 000067: I think it ok for f2k, but not for f95. The change is a nicety; we shouldn't do that retroactively. F95 is clear and consistent and there is nothing objectively wrong with it. Also, the edit refers to "literal constants" produced by formatted output; that term is wrong. Literal constants appear only in source code. Malcolm's comment on NO vote on 000067: The ANSWER states "The G edit descriptor was changed in Fortran 90 to format a real zero as if an F edit descriptor were provided in most cases. The same change was not made for list-directed or namelist output, but should have." This is not sufficient motivation for retrospectively adding an incompatibility at this stage in the proceedings. Virtually all Fortran 90 users have been aware of the list-directed output format for floating-point zeroes for much of the last decade; it is late in the day to be reconsidering Fortran 90 design choices (and making them to Fortran 95, supposedly finished up 4 years ago). We should require a much stronger reason than the one given if we wish to introduce an incompatibility between F90 and F95. Jon's comment on NO vote on 000067: The change to the F95 standard is specifying a change that was not in F90 or F95 for list-directed I/O and was not in F95 for namelist I/O, i.e., specify that a floating point zero for list-directed output and for namelist output will be written with the F format rather than the E format. Implementors may be using the G format for list-directed output and namelist output and thus may be writing a floating point zero with an F format. BUT, they may also be checking for the zero and using an E form rather than an F form. While the committee would like G format and list-directed I/O and namelist I/O to be consistent, this type of change should be done in Fortran 2000 since the change requested by the interpretation may cause some implementations to become nonstandard conforming with an interpretation. Isn't there some requirement that changes of that magnitude are supposed to be done in the next standard rather than in an interpretation? Because of the possible incompatibility with the change, we do not approve of the change for Fortran 95 but would like to see the change in Fortran 2000. Henry's comment on NO vote on 000067: The reason for the "No" vote is that the change introduces an incompatibility with FORTRAN 77, as well as with Fortran 90. The edit to 1.5.1 addresses the latter, but not the former. A similar edit to 1.5.2 is needed. A couple of minor editorial comments. In the edit to section 1.5.1, "List directed" should be "List-directed". We also recommend that the committee's usual typographical conventions be followed in the proposed edits. So, we think that four instances of "x" should be "" in the edits. F 000068 Asterisks as I/O units Kurt's comment on NO vote on 000068: I agree with the main thrust of this interpretation, but I disagree with the response to subquestion 2. I understand the cited restriction from 9.3.2 to apply to programs rather than processors. A processor may allow two units to connect to the same file or device as an extension, but a standard-conforming program is prohibited from making use of such an extension. Thus, my response to subquestion 2 would be that the processor can have more than one external unit corresponding to asterisk input or output, but that in such a case, a conforming program may use at most one such external unit. Jon's comment on No vote on 000068: The change to specify that there are specific unit numbers attached to the asterisk units and that they may appear in OPEN and CLOSE statements is extending the standard. The standard does not indicate the unit attached to the asterisk must be zero or positive. Only integer unit numbers must be zero or positive. In section 9.3 FILE CONNECTION, an io_unit is either an external-file unit, an asterisk, or an internal-file-unit. The external file unit is a scalar-int-expr. ...An external unit is used to refer to an external file and is specified by an external-file-unit or an asterisk. ... A scalar integer expression that identifies an external file unit shall be zero or positive. An asterisk identifies particular processor-dependent external units that are preconnected for formatted sequential access (9.4.4.2). The standard indicates in section 9.4.4.2 IDENTIFYING a UNIT that: ...A READ statement that does not contain an input/control list specifies a particular processor-dependent unit, which is the same as the unit identified by * in a READ statement that contains an input/output control list. The PRINT statement specifies some other processor-dependent unit, which is the same as the unit identified by * in a WRITE statement. Thus, each data transfer input/output statement identifies an external unit or an internal file. We disagree with answers 2 and 3. The answers to the questions should be: 2) Yes. The unit identified by * is not a normal unit (it is implementation defined) and thus does not fall under the restriction of 9.3.2 as cited in the discussion. 3) No. The units specified by asterisks are not normal units (implementation defined) and do not necessarily correspond to numbered units accessible to the user, and thus do not fall under this restriction. We do not approve of the addition of zero or positive unit numbers for the asterisk units for Fortran 95 or for Fortran 2000. Henry's comment on YES vote on 000068: A minor editorial comment. We recommend that the committee's usual typographical conventions be followed in the proposed edits. So, we think that two instances of "external-file-unit" should be "" and "io-unit" should be "" in the edits. C 000069 What is a numeric character? Henry's comment on YES vote on 000069: A minor editorial comment. We recommend that the committee's usual typographical conventions be followed in the proposed edits. So, we think that two instances of "" should be "<" and two instances of "" should be ">". F 000070 Asymmetry between constant specification and initialization expressions Richard Maine's comment on YES vote on 000070: Since the term "constant spec expr is no longer used", we should also remove its definition from 7.1.6.2. Jon's comment on NO vote on 000070 : The edits appear to have serious flaws and omissions. The edits to page 54 seem incomplete. The edit to 54:34 should be followed by a similar edit to 54:36 for the resulting paragraph to make sense. The same thing happens on 56:32, a similar edit is needed at 56:34. Changing "non-constant specification expression" to "not an initialization expression" (edits page 54 and 56) have some undesirable effects. For example, applying the edit to 54:32-33 results in "An automatic array is an explicit-shape array that is declared in a subprogram, is not a dummy argument, and has bounds that are not initialization expressions." The class of "not initialization expressions" includes constant expressions which are not initialization expressions, as well as expressions containing references to user defined functions! Clearly, this is beyond what an interpretation is supposed to do (BIG extension). Allowing a constant expression in an automatic array bound expression (or automatic character length, assumed size array bounds (adjustable arrays)) is contrary to what an automatic or assumed size object is and is just wrong. The actual issue is that constant specification expressions are evaluated at compile time and hence need the same limitations as initialization expressions. Nonconstant specification expressions are evaluated at run time and can be restricted expressions. The only edit necessary is to explicitly say this in section 7.1.6.2. We propose to replace all of the edits in the ballot response for 000070 with the following single edit: EDIT: For Fortran 95: Add the following constraint after R734 [95:20+]: "Constraint: If the is a constant expression it shall be an initialization expression." A corresponding edit is needed in the Fortran 2002 draft J3/00-007, [117:7+]. Henry's comment on YES vote on 000070: A minor correction for a section reference. We believe the edits on page 39 should be as follows. [39:15] Change "a constant specification expression (7.1.6.2)" to "an initialization expression (7.1.6.1)". {Fix array components.} [39:23-4] Change "a constant specification expression (7.1.6.2)" to "an initialization expression (7.1.6.1)". {Fix character string components.} F 000071 Character array constructors Malcolm's comment on YES vote on 000071: In my opinion the design of character array constructors in Fortran 90 is inherently flawed, and cannot be fixed by any simple interpretation (it really needs new syntax, like we added to the F2002 draft). If we are to reconsider the compromise solution reached at meeting 150, in my opinion we should make it more restrictive rather than going down the path suggested by Kurt of sometimes evaluating run-time expressions that are not executed. Making it less restrictive would only mean that no-one will comply with the standard until F2002 goes out for public draft anyway. Kurt's comment on NO vote on 000071: I object to this interpretation in three general areas: 1) I find the answer to be incomplete. In particular, I am perplexed by the answer to the third question. I understand the reasoning that leads to the conclusion that if the third program is standard-conforming, the length attribute of the constructed array must be 5, but I do not see how is conforms to the requirement cited from clause 4.5. (As the answer to the first question says, "There is no exclusion for s that contribute no elements to the value of the array constructor.") 2) I find the requirements of the new edit to be flawed on their own terms. It appears that the intent was to allow those expressions whose length could be determined independent of the definition status of the variables in the program. If so, it should also allow concatenations of expressions that qualify and parenthesized expressions that qualify. E.g., print *,len( (/ 'XX'//cvar1(:3)//cvar2 ,i=1,0 /) ) should reasonably be expected to print the value of len(cvar2)+5 (which is defined even if cvar1 and cvar2 are not). 3) I also disagree in two areas with the language design inherent in the edits. (Since design issues are more a matter of opinion, this objection will be more short-lived if the majority opinion of the committee lies elsewhere.) 3a) I lean towards a stronger interpretation of the requirement that all expressions have the same length. For example, I would say that the third program in the interpretation is not standard conforming, because the length of string(:f(i)) is not a constant 5. The fact that the processor may not be able to safely evaluate the length to discover this mismatch doesn't mean that the mismatch isn't there. 3b) Since I have a stronger view of the requirement for expressions to have the same length, I also tend to believe that there are more expressions whose length the processor can determine. For example, in print *, len( (/ cvar(:n) ,i=1,0 /) ) I would argue that the length of this expression is max(0,n) and that the requirement for matching lengths in effect is a requirement here that n be defined, so there is no reason it cannot be evaluated. I would like to see at least this much of an extension to the forms allowed in zero-size constructors so it would be possible to use a constructor to build zero-size arrays of arbitrary length determined during execution. (The proposed interpretation allows only constant lengths or lengths matching those of accessible variables.) Jon's comment on YES vote on 000071: We believe the concern Henry raises is moot. By the rules in 4.5, the second construct (/ (/V, i= 1, 0/) /) seems to reduce to the first (/V, i =1, 0/). (R433, ac-value may be an ac-implied-do or an expr). The outermost constructor contains an expression (another constuctor). That constructor is an ac-implied-do and it is possible to determine its length, therefore it is possible to determine the length of an element of the outer constructor. Matthijs' comment on NO vote on 000071: We agree with Henry Zongaro/Kelvin Li and Kurt Hirchert that the proposed edit is too restrictive, and that it disallows certain zero-sized character array constructors, which are currently allowed. We would like the edit to allow the following examples: (/ ('XX'//char_var_1(:3)//char_var_2, i=1, 0 ) /) (/ (CHAR(int_var), i = 1, 0) /) (/ (/ ( char_var, i = 1, 0 ) /) /) Henry's comment on NO vote on 000071: At meeting 150 this seemed like the right way to handle this problem, and Henry was aware of some of the anomalous cases Kurt raised. On further consideration, these anomalies seem too significant too ignore. Here are some other array constructors to consider. V is a character variable. According to the proposed edits, the first array constructor would be permitted, but the second would not because it doesn't have an that is an initialization expression or a variable. This seems like an undesirable inconsistency. (/(V, I = 1, 0)/) (/ (/(V, I = 1, 0)/) /) C 000072 Resolving generic procedure references Jon's comment on YES vote on 000072: See Henry's editorial comment (change non-elemental to nonelemental). Henry's comment on YES vote on 000072: A minor editorial correction. In the edit, "non-elemental" should be "nonelemental". The latter form is used six times in the standard; the former doesn't appear. F 000076 INTENT(IN) dummy arguments and implied DO loops Kurt's comment on NO vote on 000076: It is _impossible_ for a dummy argument to appear as an implied-DO variable in a DATA statement or array constructor, because even if a variable of the same is used, it is a different variable with a more limited scope. I/O implied DOs are the only ones that use a variable from the surrounding scope as the DO variable. Thus, the existing constraint is not stronger than necessary. [If we still want to make the edit to clarify the situation, I have no objection, although a change to the normative text is not required, so a note could be used instead.] Jon's comment on YES vote on 000076: We agree with Henry's edit for clarity. Henry's comment on NO vote on 000076: We have a concern about the proposed edit. A may be a , which may consist of several and s. This means there might be more than one ; the use of the definite article in the phrase "The in a " implies there is only one such . We'd like to recommend something like the following edit: [53:17] Change "A DO variable or implied-DO variable" to "A in a or an ." C 000077 INTENT(IN) dummy arguments and NULLIFY Jon's comment on YES vote on 000077: We accept Henry's edit. Henry's comment on YES vote on 000077: A minor editorial comment. A NULLIFY statement may have more than one , so the word "The" at the beginning of the line is not entirely correct. We would like to recommend the following additional edit: [53:16] Change "The of" to "A in" F 000079 Pointer Assignment and Allocatable Arrays Dick H's comment on NO vote on 000079: I think this is the wrong approach. We should try to make pointer => allocatable_target as parallel to pointer => pointer as possible. In many peoples minds pointers and allocatable are almost the same. Because of limits in F95 they are frequently used "interchangeably". Allocatable arrays have 2 significant limitations in F95. The can't be allocated in a called subroutine and they can't be used as components of a structure. The solution to these limits is to use pointers "as if" they are allocatable arrays. Yes, there are other uses for pointers; but this is a common one. The big paragraph after the constraints in 7.5.2 is clear that pointer assignment to a disassociated pointer is allowed and produces a disassociated pointer. Same thing for an undefined pointer right hand side; the left hand becomes undefined. Consider the following example: program i_79 real, target, allocatable :: x(:), y(:) real, pointer :: p(:), q(:) allocate (q(10)) p => q !legal deallocate (q) p => q !legal p => r !legal allocate (x(10)) p => x !legal deallocate (x) p => x !ILLEGAL ? p => y !ILLEGAL ? I think we would better serve the users by making pointers and allocatables parallel and treat an unallocated target array in about the same way as we treat an unallocated pointer array. I would prefer the edit to read: "If the is an allocatable array that is not currently allocated, the pointer object becomes disassociated." I could accept "acquires an undefined association status", but I haven't thought about that very much. Kurt's comment on NO vote on 000079: Because of the similarities between an unallocated ALLOCATABLE and a disassociated POINTER, my preferred way to fill in this "hole" would be to allow the pointer assignment and treat it as equivalent to nullifying P. [This is a one-shot objection. If, after consideration of this alternative, the majority of the committee still prefers to disallow these assignments, I will withdraw my objection.] P.S. The keywords on this interpretation appear to have been copied from 000071 and do not appear to be appropriate to this one. Jeanne's comment on NO vote on 000079: This needs more work. I agree with RAH and KWH that it creates an inconsistency. But even worse the edit to 99-007r2, in fact, causes a contradiction with the previous sentence because it uses the term "allocatable" rather than "allocatable array". Pointers are certainly allocatable. The new sentence says target shall be currently allocated (not allowing a pointer to an unallocated pointer), but the previous sentence [156:6-7] says if the target is undefined (not allocated) the pointer becomes undefined (allowing a pointer to an unallocated pointer). The keywords are inappropriate. Jon's comment on YES vote on 000079: As mentioned by Jeanne and Henry, the keywords are incorrect. However, Jon must, once again, disagree with Henry's tendency of filling sentences with commas, especially, when commas are not needed for clarity. (Hi Henry!) Henry's comment on YES vote on 000079: The KEYWORDS line should probably be "Pointer assignment, allocatable" In the edit to [111:18+], insert a comma after the word "array". F 000080 Host association and the EXTERNAL attribute Malcolm's comment on YES vote on 000080: Malcolm concurs with Henry's suggestion that "A procedure" should be "An external or dummy procedure". Kurt's comment on YES vote on 000080: I would have been happier with the edit in this interpretation if it had asserted the general principle that the meaning of a name in a scoping unit does not depend on how that name is used in nested scoping units, and that use of names accessed by host association is required to be consistent with the attributes given that name in the host. In all of the examples, there is the host scoping unit to make X a procedure, so it is a variable, making all of the contained procedures invalid for attempting to use X as a function. [The reference to f90 interpretation 143 in the question is a bit of a red herring, as that interpretation was more about use association than host association.] However, I have not cast a negative vote, as the edit provided is consistent with that general principle even though it does nothing to make that principle evident. Jon's comment on NO vote on 000080: No, for reason's cited by Henry (use of statement functions). Henry's comment on NO vote on 000080: We realized that a statement function is a procedure with an implicit interface that may be accessed via host association. However, it can't be given the EXTERNAL attribute as required by the edit to [283:16+]. We'd like to recommend that the words "A procedure" in the first sentence of the edit be changed to "An external or dummy procedure". In addition, the directions on the edit to [283:16+] might be unclear - it could be taken to mean that the text that follows should be added into the note rather than after it. C 000082 Usage of BOZ literal constants Jon's comment on YES vote on 000082: We prefer Henry's suggestion of using "a" instead of "the" Henry's comment on YES vote on 000082: In the edit to [32:15] "the" should be "a", as there might be more than one in a DATA statement. F 000083 Scope of array-constructor implied-DO variable Kurt's comment on NO vote on 000083: It seems far more credible to me that "the implied-DO list" was intended to mean the in the implied DO in an array constructor and the in the implied DO in a DATA statement. Additionally, this alternative is marginally more expressive. P 000084 Events that cause variables to be defined