J3/01-380 To: J3 Members Date: 24-Nov-2001 From: /interp/Stan Whitlock Subj: Results of the F95 interp letter ballot #6 Here are the results of J3 letter ballot #6 on Fortran 95 interpretations that closed on 19-Oct-2001. If I have transcribed a vote or a comment incorrectly, please let me know. J3 rep 6 7 9 26 27 66 67 68 71 86 91 95 97 Rich Bleikamp Y Y Y Y Y Y Y Y Y Y Y Y Y Malcolm Cohen C Y Y Y Y C Y Y Y Y Y Y Y (Compaq rep) no ballot received Craig Dedo Y Y Y Y Y Y Y Y Y Y Y Y Y Dick Hendrickson Y Y Y Y Y Y Y Y Y C Y Y Y Kurt Hirchert N C Y C Y N C C C Y Y C Y Bill Long Y Y Y Y Y Y Y N Y Y Y Y Y Jeanne Martin no ballot received Larry Meadows Y Y Y Y Y Y Y Y Y Y Y Y Y Dan Nagle 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 Brian Smith no ballot received Van Snyder Y Y Y Y Y Y Y Y C Y Y Y Y Matthijs/Toon Moene 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 J3 rep F90 F90 F90 F90 F90 JP JP JP JP JP JP 164 207 209 211 212 04 05 08 16 17 31 Rich Bleikamp Y Y Y Y Y Y Y Y Y Y Y Malcolm Cohen Y N Y Y Y Y Y Y Y Y Y (Compaq rep) no ballot received Craig Dedo Y N Y Y Y Y Y Y Y Y Y Dick Hendrickson Y Y Y Y Y Y Y Y Y Y Y Kurt Hirchert Y N Y Y Y Y Y Y Y Y Y Bill Long Y Y Y Y Y Y Y Y Y N Y Jeanne Martin no ballot received Larry Meadows Y Y Y Y Y Y Y Y Y Y Y Dan Nagle Y Y Y Y Y Y Y Y Y Y Y Mallory North Y Y Y Y Y Y Y Y Y Y Y Brian Smith no ballot received Van Snyder Y Y Y Y Y Y Y Y Y Y Y Matthijs/Toon Moene Y Y Y Y Y Y Y Y Y Y Y Stan Whitlock Y Y Y Y Y Y Y Y Y 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 DRAFT results is as follows: P = passed C = passed as amended F = further consideration 6 7 9 26 27 66 67 68 71 86 91 95 97 F P P P P P P F C C P P P F90 F90 F90 F90 F90 JP JP JP JP JP JP 164 207 209 211 212 04 05 08 16 17 31 P F P P P P P P P P P The interps marked "C" pass with some minor typo fixes, as noted below. The interps marked "P" and "C" became part of John Reid's WG5 letter ballot {WG5 paper N1468}. See WG5 paper N1467 for the latest listing of F95 interpretations in 006-like format. The interps marked "F" will be reconsidered at J3 meeting #159 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 000006 Character length specification of a function result Cohen's COMMENT on 6: Kurt mentions that we are supposed to be object-code compatible with F77. That's nice, but the $66 question is whether this would be object-compatible with existing F90/95 processors. If it is compatible (e.g. because all the F90 vendors implemented assumed-character-length dummy functions, perhaps because that's what the words in the F90 standard as well as the F95 standard require), there would not seem to be a problem. Certainly making F95 backwards-compatible in the way Kurt suggests would make it incompatible with F90. It's not as though the words in F90 aren't clear on this topic. Hirchert's NO vote on 6: It appears to me that adopting this interpretation would create incompatibilities with FORTRAN 77 at the object code level. [Reminder: One of the design goals for Fortran 90 was to make it object compatible with FORTRAN 77 as well as being source compatible, so Fortran 90 processors could make use of libraries intended for use by existing FORTRAN 77 processors on the same platform. It was not practical to mandate such object compatibility, so the effect of this goal was to avoid imposing requirements that would force the Fortran 90 processor to be incompatible. As far as I know, we were 100% successful in the respect. I remember no discussions of this goal in the context of Fortran 95, but I believe there was no intent to abandon this object compatibility.] This interpretation requires a Fortran 95 processor to support assumed-length dummy functions. In order to do this, the scoping unit providing the corresponding actual argument must supply the actual length associated with that function, as well as the address of the code that implements it. Because the interface may be implicit, the calling procedure cannot tell whether a character function argument corresponds to an assumed-length dummy procedure, so this length information must be supplied for all arguments that are character functions. However, FORTRAN 77 did not allow assumed-length dummy functions (because they would have violated its design goal of being implementable without dynamic storage allocation). Thus, there is no reason for a FORTRAN 77 caller to supply this length information or for a FORTRAN 77 procedure to be prepared to receive it. I can think of at least three ways my vote might be changed to YES: 1. Change the answer so Fortran 95 is consistent with FORTRAN 77 in prohibiting assumed-length dummy functions. 2. Continue to require support for assumed-length dummy functions, but add edit to make this require an explicit interface (so caller need provide length information only when dummy argument is known to be an assumed-length dummy function). 3. Prove to me that I am misinterpreting FORTRAN 77. 000007 Optional intrinsic function arguments Hirchert's COMMENT on 7: Although I am in complete agreement with the technical content of this response, I find myself slightly uneasy about the failure of the text to address the heart of the question that lead to the interpretation request -- the misinterpretation of our earlier response. In the response to the earlier interpretation cited in the question, we agreed "in principle" because that question correctly identified a problem in the Fortran 90 standard and proposed a repair that would have been sufficient to eliminate the problem, but we adopted a "more appropriate" edit because, in part, the proposed solution unnecessarily prohibited cases that did not suffer from the original problem. In particular, the original problem does not occur when the actual argument is scalar (as in this question). 000026 List-directed input: types of variables corresponding to repeated values Hirchert's COMMENT on 26: As with interpretation 25, I would have preferred a slightly different interpretation, but I am willing to accept this one. 000066 Errors in processing data transfer statements Cohen's COMMENT on 66: Kurt mentioned: >>For example, consider information >>transferred on a communications line with a CRC at the end. Noise on the >>line might garble the value transferred into IDX, but the error would not >>be detected until the end of the transfer, so the transfer into A(IDX) >>might go to some unfortunate location. IMO it behooves the processor to check the CRC before accepting the garbled values, at least when the user has specified ERR= or IOSTAT=. Failure to do so is sloppy (not merely "fragile") programming inside the processor. Hirchert's NO vote on 66: I am largely satisfied with the edit, but less satisfied with the supporting discussion. I agree that in the specific case mentioned in the question (an error in the transfer of J), there is no intent that the program not be standard conforming. However, there are other cases. For example, consider information transferred on a communications line with a CRC at the end. Noise on the line might garble the value transferred into IDX, but the error would not be detected until the end of the transfer, so the transfer into A(IDX) might go to some unfortunate location. Of course, this could just as easily have happened if a bad value had been transferred for IDX without any error. This style of programming, though quite common, is inherently fragile. 000067 Writing zeros Hirchert's COMMENT on 67: I would have preferred to have corrected the text to say what we intended, but I bow to the will of the majority. 000068 Asterisks as I/O units Hirchert's COMMENT on 68: I am uneasy about the answer to question 2. I would have read the cited restriction as applying to the program rather than the processor, so I would have thought a processor would be allowed _as_an_extension_. As long as the program neither attempted to connect two units to the same file nor depended on two preconnected units being connected to the same file, I would have judged it not to have violated this requirement. (On a Unix system, if my program writes to units connected to stdout and stderr, is my program (or the processor) non-conforming if both are connected to /dev/tty, but conforming if they have been redirected to separate files?) Long's NO vote on 68: In discussion for item (2), the word "device" does not match the wording in the standard. We would prefer "unit". The Answer for (3) should be NO. The * cannot explicitly be specified in a CLOSE statement ([138:10] and [143:19]). If a numbered unit is connected to the same file as the * unit, as described in the Discussion text, then closing the numbered unit does not cause the * unit to become disconnected. Proposed alternate reply for question 3: ANSWER: 3. No DISCUSSION: 3. The asterisk may not appear as a unit number in a CLOSE statement. The asterisk may not be disconnected from the associated processor-dependent external unit. A processor extension may have two units connected to the same file, e.g. unit 6 and the * output unit might both identify the user's standard output file. This is not detectable by a standard-conforming program; but in this case, closing unit 6 would not necessarily affect output to the standard output file via *. 000071 Character array constructors Hirchert's COMMENT on 71: I am concerned about the text of the edit. Consider the following example: call sub( (/ (s(:i-1)//s(i+1:),i=2,len(s)-1) /) ) It could be argued that the length of the ac-value in this example is len(s)-1, a value independent of i, and that therefore this constructor should be acceptable, but since we determine that by adding the two values (i-1) and (len(s)-i), I suspect that processors do not really want to have to deal with this kind of case. Snyder's COMMENT on 71: If we correct typo's in the QUESTION part of interpretation requests, "antipenultimate" should be "antepenultimate". >>000071: This suggestion is accepted. 000086 Definition status requirements for defined operations Hendrickson's COMMENT on 86: The HISTORY should reference paper 297, not 158-mjc-013 >>000086: This suggestion is accepted. 000095 Names of functions, results and entry points Hirchert's COMMENT on 95: I am far from convinced that this is what was intended. While I strongly agree that there was no intent to allow (8), (9), and (10), I would have supposed that it would have been our intent to _allow_ (4) and (7), and I would have considered it possible that we would have allowed (5). In other words, I would have thought that our intent was a. Within a function, the only two allowed uses for the name of the function are to denote the function or to denote its result variable. (This would be the rule that prohibits (8), (9), and (10).) b. In a function with entry points, several entry points may use the same result variable. (This would be the basis for allowing (3), (4), (5), (6), and (7).) c. If the result variable for a function is to have the same name as the function itself, this cannot be denoted explicitly using a RESULT clause; instead, it is denoted implicitly by omitting the RESULT clause. (This is what prohibits (1) and (2).) I think allowing (3) and (6) but disallowing (4), (5), and (7) is a fairly peculiar interpretation. All it really does is force extra declarations. For example, in (4), one could change RESULT(F) to RESULT(F2) and add declarations to give F2 the same attributes as F. Because F and F2 are associated, one could then continue to use F as though it were the result variable for E. I think forcing these duplicate declarations is silly and not what we intended, but then again, I thought it silly to prohibit (1) and (2). It is possible to work around these silly restrictions, and there is nothing about imposing them now that would preclude our removing them in the future, so my vote is a very reluctant YES. F90/000207 Integer bit-model inconsistency Cohen's NO vote on F90/207: Kurt remarks: >>From my perspective, the heart of the problem is that 13.5.7 has >>editorial problems that obscure the intended technical content. However, >>the intended technical content is known, and I am aware of no technical >>defects in it. Therefore, the appropriate action would appear to be to >>correct the editorial problem rather than to make an incompatible >>technical change. Kurt's claim for intended technical content is far from clear to me. The text of the standard itself is not adequate, as it assumes that every integer greater than one is equal to two. The quoted authority of MIL-STD-1753 is not adequate, as it appears not to address the issue (it just says that "it is assumed that the integer arguments m and n are represented in binary form", and makes no comment about processors where integer arguments are not represented in binary form). Anyway, the proposed edit looks to me like it is exactly the "editorial" level fix. It merely fixes the incorrect claim (that two incompatible models are identical) without making any technical change. If the committee really wants to proceed along the lines Kurt suggests, there are a number of edits required to assert the conversion to/from binary form and to adequately specify that form. For instance, it would certainly be unclear as to what BIT_SIZE is meant to return. >>2. The proposed edits are inadequate. [...] >> b. The proposed change means that the examples in the descriptions of >>the various bit intrinsics are correct only on machines whose integer >>radix is 2, but this edit fails to add the necessary qualifications and >>caveats to those examples. Kurt is correct, when I looked at these the last time they all appeared to be correct on the "interesting" machines, but I missed at least one case ([245:2]). And perhaps we ought to consider less likely machines (e.g. ternary) anyway. >> b. Even if you don't care about the disconnect between bits and >>values, it will be difficult to use the bit intrinsics in ways that are >>safe on all platforms. For example, you might be tempted to write >> I=IBSET(I,N) >>to set bit N of variable I, but the result of setting this bit might be >>an invalid representation (e.g., a digit greater than 9 on a decimal >>machine) so this assignment (which nominally operates on I as an integer >>value rather than a collection of bits) might "blow up". (An early Kurt's "preferred solution" is no better. On a decimal machine either BIT_SIZE is too small, and so the user cannot decompose some numbers into bits, or it is too big, and he can get an integer overflow trying to convert the bits back to an integer value. Or maybe the machine has no support for out-of-decimal-range-bit-values, in which case sometimes he cannot "set the bits" even though BIT_SIZE would tell him that he can. Hirchert's NO vote on F90/207: What follows is only a subset of my objections to this interpretation (but I don't really have the time to write up all of them, and I doubt you want to read them all): 1. This interpretation is procedurally inappropriate. From my perspective, the heart of the problem is that 13.5.7 has editorial problems that obscure the intended technical content. However, the intended technical content is known, and I am aware of no technical defects in it. Therefore, the appropriate action would appear to be to correct the editorial problem rather than to make an incompatible technical change. 2. The proposed edits are inadequate. a. It appears to me that the heart of the editorial problem is that 13.5.7 presents a model that is _never_ used in its entirety. Enlarging the cases where it is not used exacerbates the problem and makes this section even less clear. b. The proposed change means that the examples in the descriptions of the various bit intrinsics are correct only on machines whose integer radix is 2, but this edit fails to add the necessary qualifications and caveats to those examples. 3. The technical implications of this interpretation are highly undesirable. a. It would not longer be portably assume _any_ connection between the value of an integer variable and its content viewed as bits. The implications of that change are wide-ranging. The following are a few examples: (1) Setting a variable to 0 can no longer be assumed to set all bits to 0. Instead, one must run a loop from 0 to BIT_SIZE(0)-1 and use IBCLR to clear each bit individually. (2) Similarly, one can no longer use BOZ constants to portably set particular bit patterns. Once again, one would have to use IBSET and IBCLR to set each bit separately. (3) Likewise, BOZ edit descriptors can no longer be depended upon to usefully read and write bit patterns. (More things to do with IBSET, IBCLR, and BTEST.) (4) There are a variety of algorithms that involve either building integer values from sums of powers of 2 or decomposing integer values into sums of powers of 2. Prior to this interpretation, one could efficiently implement these algorithms using the bit intrinsics. If the effect of these intrinsics can no longer be depended upon to relate to these powers of 2, one must revert to using integer divide and remainder in order to code such algorithms portably. I suspect that many committee members voted for allowing these intrinsics to work on "the real bits" in the assumption that this would allow more efficient implementations of the bit intrinsics on non-binary platforms. Although the intrinsics might be more efficient, portable programs end up less efficient because the programmer can no longer depend on the intrinsics to perform the operations needed. b. Even if you don't care about the disconnect between bits and values, it will be difficult to use the bit intrinsics in ways that are safe on all platforms. For example, you might be tempted to write I=IBSET(I,N) to set bit N of variable I, but the result of setting this bit might be an invalid representation (e.g., a digit greater than 9 on a decimal machine) so this assignment (which nominally operates on I as an integer value rather than a collection of bits) might "blow up". (An early implementation of FORTRAN on the IBM 360 used IBM's decimal arithmetic and would do exactly that when you loaded a variable with bits that were not a valid decimal representation.) To be safe, you would need to write something like CALL MVBITS(IBSET(I,N),0,BIT_SIZE(I),I,0) so the result of IBSET would be transferred as a collection of bits rather than an integer value. [In reality, I suspect many people would ignore (or be unaware of) the portability problems or would address them by writing an emulation of the binary semantics of the bit intrinsics to be used on non-binary machines. Do we really believe it better to hide portability bombs, and/or make users (rather than vendors) write the portable versions of these intrinsics? I certainly don't!] JP-17 Multiple occurrence of namelist group object in namelist group Long's NO vote on JP-17: The current standard does not forbid the presence of a namelist-group-object from appearing in a NAMELIST more than once. There is no motivation for why this should be changed. The change could result in standard-conforming codes becoming non-conforming. Note that the use of NAMELIST was to provide a method of getting a list of names and values without specifying each name in an I/O list. In an I/O list, a name may appear more than once. The same flexibility should be allowed for NAMELIST. This could have practical application. For example, the list could include a character variable that contained a banner line that the user wants printed at the beginning and also at the end of the output. Proposed alternate reply: ANSWER: YES EDITS: (none)