From jkr@jkr.cc.rl.ac.uk Tue Aug 8 20:16:32 2000 Received: from nameserv.rl.ac.uk (nameserv.rl.ac.uk [130.246.135.129]) by dkuug.dk (8.9.2/8.9.2) with ESMTP id UAA57421 for ; Tue, 8 Aug 2000 20:16:32 +0200 (CEST) (envelope-from jkr@jkr.cc.rl.ac.uk) Received: from jkr.cc.rl.ac.uk (jkr.cc.rl.ac.uk [130.246.8.20]) by nameserv.rl.ac.uk (8.8.8/8.8.8) with ESMTP id TAA21311 for ; Tue, 8 Aug 2000 19:16:31 +0100 Received: (from jkr@localhost) by jkr.cc.rl.ac.uk (8.8.8+Sun/8.8.8) id TAA23387 for SC22WG5@dkuug.dk; Tue, 8 Aug 2000 19:17:37 +0100 (BST) Date: Tue, 8 Aug 2000 19:17:37 +0100 (BST) From: John Reid Message-Id: <200008081817.TAA23387@jkr.cc.rl.ac.uk> To: SC22WG5@dkuug.dk Subject: N1395 Ballot results MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Dear WG5, Here is document N1395 containing all your votes and comments on the interpretations that we balloted. Since the draft, I have added votes from Hirchert, Muxworthy, Steidel, and van Waveren. Please will you four check your parts? I have also corrected an error in the summary table (for a Reid vote!). My impression is that we have sufficent agreed edits that we should construct a draft of Corrigendum 1 at Oulu. Of course, we need also to consider all the comments. Best wishes, John Reid. ISO/IEC JTC1/SC22/WG5-N1395 Results of the ballots on interpretations John Reid, 28 July 2000 90/ 90/ 90/ 90/ 67 68 69 70 71 72 76 77 79 80 82 83 84 100 179 185 194 Cohen n y y yc y y y n y y y y y y y y y Dedo y y y yc y y y yc y y y y y Delves y y y y y y y y y y y y y Gorelik y y y y y y y y y y y y y y y y y Hendrickson y y y y y y y y y y y y y y y y y Hirchert yc yc y y n y y y yc y y yc y y y y y Kruyt y y y y y y y y y y y y y y y y y Kuester y y y y y y y y y y y y y Maine n y y y y y y y y y y y y y y y y Martin y y y y y y y y y y y y y y y y y Meadows y y y y y y y y y y y y y y y y y Morgan y y y y y y y y y y y y y y y y y Muxworthy n y y y n y y yc yc y y y y y y y y Nagle y y y y y y y y y y y y y y y y y North y y y y y y y y y y y y y y y y y Reid n y y yc y y y y n y y y y y y y y Schoenauer y y y y y y y y y y y y y y y y y Snyder y y y y y y y y y y y y y y y y y Steidel n n y yc y y y y y y y y y y y y y van Waveren y y y y y y y y y y y y y y y y y Warnock y y y y y y y y y y y y y y y y y Weber y y y y y y y y y y y y y y y y y Whitlock y y y y y y y y y y y y y y y y y Zongaro n y y yc n y y y y y y y y y y y y Comments and reasons for no votes 67 Cohen This interpretation is not fixing a problem in the standard, but making an incompatible change - incompatible with Fortran 77 and Fortran 90, and with the published Fortran 95. No problem has been identified which justifies making this incompatible change in a retroactive manner. Should "magnitude x" in the edits not be "magnitude " in every case? 67 Maine Two separate reasons, either of which would merit a "no" vote. 1. Appropriateness. There is no defect here. Nothing here is unclear or internally inconsistent in the standard as published. This appears to be nothing more than an attempt to retroactively make a change to the language. This is not a proper thing to do in an interpretation. It sounds like an MTE....but the time for MTEs for f95 has passed by at least half a decade. Furthermore, the change is incompatable with f90 and with f95 as published. Both f90 and f95 explicitly required one form, while this change explicitly disallows that form and requires a different form. This interpretation makes *every* formerly conforming f95 processor now be non-conforming, and it makes any f90 or f95 program that depended on the f90 behavior now invalid. If such a change were made, it would merit mentioning in the list of incompatabilities in section 1. (It seems more pertinent than some of the things already listed there). 2. Technical error in the edits. The edits refer to the "constants" produced by formatted output. The term "constant" is inappropriate here. Formatted output produces sequences of characters - not constants. F90 interp 131 went to a lot of trouble to fix such incorrect usage of the term "constant". We should not re-break it. A constant has a type and type parameters - formatted output does not. The allowable forms of literal constants are not the same as the allowable forms of formatted output (notably, formatted output never includes kind type parameters). 67 Zongaro Minor comment: The edit to [4:24+], mentions the behaviour of namelist output. Because FORTRAN 77 did not include support for namelist, it's not necessary to mention the change in behaviour. We would recommend changing the start of that edit from "List directed and namelist output statements" to "List-directed output statements". In the edits to [3:32+] and [4:24+], "List directed" should be "List-directed". Substantive comment: We do not believe that the fact that X3J3 changed the representation of real zero under a G edit descriptor, but not in list-directed output, was an oversight. X3J3 was specifically asked to consider changing the G edit descriptor in paper 88(11) JHM-1 "SG11 Clean-up proposals"; that request made no mention of list-directed output. As has been pointed out by Malcolm Cohen and Richard Maine, the treatment of real zero in list-directed output is well-known. Any change would affect many verification files for user programs, not to mention similar verification files in compiler test suites. Such a change should not be entered into lightly in interpretation processing. 67 Reid I agree with Malcolm Cohen and Richard Maine 67 Steidel This is an incompatable change with F77 and F90. The change could be made to F2k, but should not be made as a "fix" to F95. 67 Muxworthy I agree with Malcolm, Rich and Henry. 67 Hirchert I find this "change" acceptable because I believe this is what the f90 committee intended. 68 Steidel As with interpretation 67, this is an incompatable change and will causes implementations to no longer be standard conforming. This change should not be made as an interpretation to an existing standard but may be made to a future (F2K) standard. 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. 68 Hirchert I'm voting yes because I believe the edit to be correct, but I believe the answers and discussion can be misconstrued. In my experience, there are two ways that, for example, the input asterisk unit and unit 5 could come to be "the same thing": 1) They could be the same unit (as clarified by the edit). In this case, closing unit 5 affects the input asterisk because they are the same unit and thus the same connection. 2) They could be separate units connected (as a processor extension) to the same file. (A standard-conforming program is not allowed to connect two units to the same file, but I believe that a processor is allowed to do so as an extension, and that as long as a program uses only one or the other of those units, it is not using the extension and thus not nonconforming on that basis.) In this case, I would expect closing unit 5 to have no effect on the asterisk unit because they are different units and have independent connections to files. The interpretation focuses primarily on case 1 (because case 2 involves an extension), but, in my experience, case 2 is the more common implementation, so there is a potential for misunderstanding. 70 Cohen The edits to [54:36] and [56:34] create references to "bounds expression variables". Ugh. I don't know what bounds expression variables are - 3 possibilities spring immediately to mind: (1) variables that are the entirety of the bounds expression (2) variables that appear within a bounds expression (3) variables that would affect the value of a bounds expression, e.g. which are in common and are read by a user-defined function. Anyway, the sentences on [54:36-37] and [56:33-34] do not appear to add anything not already a consequence of their immediately preceding sentences. It would be less confusing if they were notes rather than normative text. Suggested alternative edits: [54:36-37] Change "the specification expression variables" to "any variables". [56:34-35] Ditto. 70 Dedo I agree with Malcolm Cohen's preferred edits for [54:36-37] and [56:33-34]. However, the sentences in question should remain normative text. 70 Zongaro An editorial comment: the edits on page 39 need to update the section references. [39:15-16] Change "a constant specification expression (7.1.6.2)" to "an initialization expression (7.1.6.1)". {Fix array components.} [39:23-24] Change "a constant specification expression (7.1.6.2)" to "an initialization expression (7.1.6.1)". {Fix character string components.} 70 Reid I think a better edit for [54:36-37] and [56:34-35] would be Change "the specification expression variables" to "a variable". 70 Steidel See Henry's comments. 71 Zongaro Consider the following array constructors, where V is a character variable: (/(V(I:I), I=17,15)/) (/('ABC'(J:J), J = 2, 0)/) According to the proposed edits, we believe both of the preceding array constructors would be permitted as zero-sized character array constructors. Subclause 7.1.6.1, list item (8) states that an array constructor implied-DO variable is an initialization expression, if its bounds and stride are initialization expressions; that is the case for both I and J in the examples. List item (1) states, along with [94:28-29] that a subobject of a constant is an initialization expression, if the substring starting point and substring ending point are initialization expressions; that is the case for 'ABC'(J:J). In the first case, the array constructor has an that is a variable with a in which all expressions are initialization expressions; in the second case, the array constructor has an that is an initialization expression. Hence, both comply with the proposed edit to [45:38+]. However, it's not clear what is the length of either array constructor, which is what this interpretation was intended to clarify. In addition, we're still concerned about the anomalies that this change introduces. Consider the following examples, where 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)/) /) 71 Muxworthy I would like to see answers to the points Henry raises before voting yes. 71 Hirchert I oppose this item because I feel that it fails to adequately answer the question asked and that it raises at least as many questions as it answers, possibly because one of the specific answers it gives it wrong. Although never explicitly stated as a question, the original inquiry clearly is asking about how the rules on type parameters in array constructors are to be applied to zero-trip implied DOs. The answers supplied only minimally address the application of the existing rules, focusing instead on the imposition of new rules. The answer that I believe may is incorrect is the answer to the third explicit question. The reasoning there shows that the character length of the array constructor cannot be something other than 5, but it does not show how this constructor meets the requirement "If the expressions are of type character, each expression in the shall have the same character length parameter." I suggest that it does not. Consider the following sequence of transformations to the program in the third specific question: - Change "f = 2*i + 5" to "f = 2*i + 4". - Change "f = 2*i + 4" to "f = 0*i + 4". - Change "f = 0*i + 4" to "f = 4". - Change sub so it uses a variable f that has been set to 4, rather than invoking the function f that returns 4. - Change the variable f to a constant 4. Given the statement that "There is no exclusion for s that contribute no elements to the value of the array constructor: thus s that are inside zero-trip implied DO loops still contribute their "type" information," I believe that the final result of this transformation clearly does not conform, and I see no obvious point in the transformations at which it would have switched from conforming to nonconforming, so I conclude that the original program also did not conform, contrary to the statement in the answer. For this reason I vote against this item. I also believe that the new rules imposed by this item are ill-chosen. If that were all that was wrong with this item, it is likely that I would act as I have on several other items in this ballot and comment without voting no, but since I believe this item needs further work, I would suggest that the rules also be subject to further consideration. I offer three objections to the rules proposed: 1. When imposing rules on an aspect of the language that has nominally been unrestricted until now, I would expect the new rules to impose only as much restriction as was absolutely necessary. Instead, these rules are only minimally permissive. Such an approach may be appropriate when introducing new features to the language, but I find it inappropriate when modifying an already published standard. 2. It is desirable if the rules reflect some inner consistency. The basis for these rules appears to be those expressions whose length can be determined without depending on any variables to be defined, but it omits the concatenation of strings whose length is known in this way. (I think this underlying rationale is too restrictive, but the rules should at least allow that which fits the rationale.) 3. It may be acceptable to restrict the way in which zero-length arrays are constructed, provided a minimum level of functionality remains available. In this case, it is desirable to be able to construct zero-length character arrays of arbitrary character length (determined at execution). The proposed rules do not provide this functionality, allowing only construction of constant lengths or lengths that match the length of accessible character variables. 77 Cohen Reinstate page and line numbers "[53:16]" in the edit instructions. Change "The " in the edit to "A ". Change "" in the edit to "". 77 Dedo I agree with Malcolm Cohen's editorial changes. Could this be done as a post-ballot editorial fixup? I would hope that we don't need to re-ballot this interp. 77 Muxworthy I agree with Malcolm's point that the proposed edit is incorrect as it stands. 79 Reid I think it would be more friendly and consistent to say that pointing to an unallocated allocatable array is legal and gives an unassociated pointer. I tried this little program on the 5 compilers (Epc, Nag, Fujitsu, Digital, SUN) to which I have ready access: program main real, allocatable, target :: a(:) real, pointer :: p(:) allocate (p(2)) write(*,*)associated(p) p => a write(*,*)associated(p) end program main They all ran and gave the output T F 79 Muxworthy I prefer John's alternative response but do not feel strongly. 79 Hirchert My preference would have been to allow such pointer assignments, specifying that this makes the pointer null, but I can accept this. 83 Hirchert I vote for this item reluctantly. I believe it to be an incorrect interpretation of the existing text in the standard. I find implausible the suggestion that the author of this section substituted the undefined phrase "implied-DO list" for the _shorter_ defined phrase "implied DO". It seems much more likely to have been a substitution for a longer phrase, probably one containing the word "list". An obvious candidate is " in the implied-DO". The discussion dismisses this alternative with an inelegant phrasing, but I feel that unfairly ignores the elegance of having the scope of the implied-DO variable extend to those portions of the implied DO where it can legally be used and not to those portions where it cannot. Having said all this, the difference between the correct interpretation and the incorrect interpretation offered here is minor. Programs that exploit the difference between them are obfuscated and likely to run into implementation errors. I am annoyed by this gratuitous language change that serves only to reduce the set of conforming programs with no corresponding gain, and I would have preferred a clarification that reflected the correct interpretation, but my objection is largely aesthetic, so I comment without a negative vote.