From jkr@jkr.cc.rl.ac.uk Fri Jul 28 16:37:51 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 QAA18548 for ; Fri, 28 Jul 2000 16:37:51 +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 PAA21763 for ; Fri, 28 Jul 2000 15:37:50 +0100 Received: (from jkr@localhost) by jkr.cc.rl.ac.uk (8.8.8+Sun/8.8.8) id PAA20404 for SC22WG5@dkuug.dk; Fri, 28 Jul 2000 15:38:58 +0100 (BST) Date: Fri, 28 Jul 2000 15:38:58 +0100 (BST) From: John Reid Message-Id: <200007281438.PAA20404@jkr.cc.rl.ac.uk> To: SC22WG5@dkuug.dk Subject: Preliminary results of the ballots on interpretations MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Dear WG5, Here is a draft of the document N1395 that will contain all your votes and comments on the interpretations that we are balloting. Please check your part and let me know if I have got it wrong or if you want to change anything. 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 (draft) 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 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 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 y n 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 Schoenauer 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 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". 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)/) /) 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. 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