From janshep@watson.ibm.com Mon Oct 9 18:58:17 1995 Received: from watson.ibm.com (watson.ibm.com [129.34.139.4]) by dkuug.dk (8.6.12/8.6.12) with SMTP id SAA17885 for ; Mon, 9 Oct 1995 18:57:45 +0100 Message-Id: <199510091757.SAA17885@dkuug.dk> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 9091; Mon, 09 Oct 95 13:56:18 EDT Date: Mon, 9 Oct 95 13:56:17 EDT From: "Janice C. Shepherd ((914) 784-6313)" X-Addr: J1-K10, Hawthorne 2 tieline 863 To: sc22wg5@dkuug.dk Subject: X3J3 006 ballot This is the result of the X3J3 006 ballot. Sorry for the reminder that you received multiple copies of (I had only sent one; it appears the problem may have been caused by the reflector). Mallory: please include this in the premeeting for meeting 135. Thanks. Janice --------------------------------------------------------------------- X3J3/95- page 1 of To: X3J3 From: Janice C. Shepherd Subject: Results of the post meeting 134 006 letter ballot This document contains: 1) a summary of the vote counts and whether each item passed or failed 2) a list of the editorial corrections I made to defect items which passed 3) ballot comments (sorted by defect item #) If anyone finds any errors in the ballot results, please send them to me as soon as possible. Janice - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - +-Yes votes | +-Yes with Comments | | +-No votes | | | +-Pass or Fail v: v: v: v Y:wc: N: P/F Defect# short description 9:1: 6: F 000081 Pointer actual argument overlap 8:7: 1: P 000083 Extending generic intrinsic procedures 13:2: 1: P 000125 Copy in/copy out of target dummy arguments 9:6: 1: P 000175 What is a "constant specification expression"? 6:4: 6: F 000179 DO variable with POINTER attribute 10:5: P 000198 Characteristics of dummy procedures 15:1: P 000199 Kind Type Parameters and the DELIM= specifier 9:1: 6: F 000202 Evaluation of intrinsic procedures items passed:5 items failed:3 A total of 16 votes and two sets of comments (John R., Malcolm C.) were received. An item needed MAX(11,12) to pass (2/3 of 16 votes, more than 1/2 of 22 J3 members). So an item needed 12 yes votes to pass. While Henry and I both have comments we only count for one vote. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Editorial corrections made to items: 81 Answer 4: delete "of" prior to "INTENT(IN)" Edit 2: change single quotes to double quotes. Edit 6: delete extra quote at end. 83 Edit 1: Add at start of sentence "In a scoping unit" Edit 3: Replace text with: "If a generic name is the same as the name of a generic intrinsic procedure, the generic intrinsic procedure is not accessible if the procedures in the interface and the intrinsic procedure are not all functions or not all subroutines. If a generic invocation applies to both a specific procedure from an interface and an accessible generic intrinsic procedure, it is the specific procedure from the interface that is referenced." 175 Replace Answer text with: ANSWER:A constant specification expression is a specification expression that is also a constant expression. An edit is supplied to define this term. The edit is needed to make it clear that it is not sufficient for the value of the specification expression to be fixed. For example, if IC is a named constant with value 0 and I is a dummy argument, IC*I always has the value 0, but this is not a constant specification expression. 198 Discussion: first sentence, delete "those of" Edit: change "and" to "as for" 199 Question: remove blank prior to "?" 202 Question: add "if it" after "; but" Answer: first sentence change "form" to "from" Replace "Standard" with "standard" 3 times. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Ballot Comments: Item Yes Who Comment # /No --------------------- 000081 Pointer actual argument overlap 81 N Bierman I buy the IBM reasoning enough to reject this at this point. 000081 N Hirchert The Zongaro comments lead me to believe that this item has become intertwined with the 000125 fiasco. 81 N Maine I agree with the concerns of Janice and Henry. There is lots of existing code like Henry's sample; making it illegal would be completely unacceptable. This needs to be either fixed or at least clarified. Publishing it without making it perfectly clear that Henry's code is legal guarantees another interpretation request. 81 N Martin The problem raised by Zongaro should be corrected. Editorial suggestions: Answer 4: delete "of" before INTENT (IN); Edit 2: replace apostrophes with quotes (they are mixed in this item - quotes are used elsewhere); Edit 6: delete extraneous apostrophe at end. 0081 Y Rolison I do not find the arguments by Shepherd and Zongaro to be compelling. They boil down to (I believe) this. If we have a program fragment such as: TYPE one INTEGER i END TYPE TYPE two TYPE(one), POINTER :: p END TYPE TYPE(two) s ALLOCATE(s%p) does I somehow magically become a subobject of S due to the ALLOCATE? I assert that this is impossible because the notion of subobject is a syntactic notion, not a dynamic notion. Also consider that when the standard breaks down a structure into "ultimate components" it stops at a component that is a pointer. Therefore, the chain of pointers that Henry presents does NOT lead to any subobject of some other derived type and thus the wording of Interp 81 is OK as is. 81 N Shepherd The issue raised by Henry is based on the wording in the edit that adds restrictions on changing the pointer association status of ANY PART of the entity. Section 6.1.2 where structure components are defined does not indicate that ptr%t is not a "part of" 'ptr' but a part (or all) of the target of 'ptr'. An edit to 6.1.2 should be added to defect 81. 81 N Terpstra I agree with Henry's analysis of this question. 81 Zongaro The concern is of a technical nature. Permitting the values of the entities or any of their subobjects to be changed while not permitting the association status to be changed seems inconsistent and restrictive. Consider the following example, PROGRAM PTR_EXAMPLE TYPE LIST_NODE INTEGER :: VALUE TYPE (LIST_NODE), POINTER :: NEXT END TYPE LIST_NODE TYPE (LIST_NODE), TARGET :: HEAD, SOME_NODE ALLOCATE(HEAD%NEXT) ALLOCATE(HEAD%NEXT%NEXT) HEAD%NEXT%NEXT%NEXT => HEAD CALL INSERT(HEAD, SOME_NODE) CONTAINS SUBROUTINE INSERT(NODE, NEW_NODE) TYPE (LIST_NODE), TARGET :: NODE, NEW_NODE NEW_NODE%NEXT => NODE%NEXT ! Ptr assign 1 NODE%NEXT => NEW_NODE ! Ptr assign 2 END SUBROUTINE INSERT END PROGRAM PTR_EXAMPLE Graphically, before the call we have the following circular linked list: HEAD __ __ __ -->|__|--->|__|--->|__|-- | | |________________________| and we want to insert SOME_NODE into the list. The problem is that because the list is circular, after the first pointer assignment, NEW_NODE%NEXT%NEXT%NEXT is pointer associated with NODE. Thus, the second pointer assignment to NODE%NEXT affects NEW_NODE%NEXT%NEXT%NEXT%NEXT. This would be prohibited by the proposed edits. Is this really what the committee intended? --------------------- 000083 Extending generic intrinsic procedures 83 Ywc Barber I assume edit 1 applies within a given scoping unit but not across host and contained scopes so as to be consistent with 14.1.2.3. I suggest inserting the text "In a scoping unit" at the start of edit 1 to clarify this 83 Y Bierman Go with Reid version. 83 Y Hendrickson I like John Reid's proposed rewording 83 Y Maine I agree with John Reid's suggested change to the edit. 83 Y Martin John Reid's edit 3 is preferable. 83 Y North I agree with the comments by John Reid 83 Ywc Reid In edit 3, the use of the term "specific intrinsic procedure" is misleading here since it has a precise and other meaning. It might have been OK immediately after the first paragraph of the section, where we say that each intrinsic is interpreted as a collection of specific procedures, but is not OK here. In any case, it is not needed. Here is a suggested revision of the edit: "If a generic name is the same as the name of a generic intrinsic procedure, the generic intrinsic procedure is not accessible if the procedures in the interface and the intrinsic procedure are not all functions or not all subroutines. If a generic invocation applies to both a specific procedure from an interface and an accessible generic intrinsic procedure, it is the specific procedure from the interface that is referenced." 0083 N Rolison I have always voted against this one and I will continue to vote against this one every time it comes up. There is a *basic* rule in the language that you cannot override intrinsic operators for operands for which they are intrinsically defined, and you can not override intrinsic procedures for arguments for which they are intrinsically defined. Since people are complaining about Interp 179 allegedly redesigning the language at this late date, why are those same people not complaining about this one redesigning the language at this late date? If that excuse works for 179, then I invoke it for this one. 83 Y Shepherd Use John Reid's version of Edit 3 83 Zongaro The same problem described by this defect item occurs with defined assignment of derived types. If intrinsic assignment is treated as if a hidden generic interface existed (as the text quoted in section 14.1.2.3 implies), such an interface would define hidden specific procedures for the intrinsic types and for any derived types which existed in the program. The standard permits a program to redefine assignment for objects of a derived type, but such a specific procedure which did this would conflict with the "hidden" specific described above, in the same way as it would in the case of intrinsic procedures. A new defect item should be opened for this issue. --------------------- 000125 Copy in/copy out of target dummy arguments 125 Ywc Barber I commend X3J3 and in particular Janice and Larry for the mountain of effort they have put into fixing this issue. However it has to be said that the pointer/target/argument rules are so complicated that I fear mere programmers will be forever baffled by them. It might be helpful to the future writers of compilers and text books if a rationale could be written at some point to explain the problems and the origins of the rules. 125 N Hirchert This appears to be somewhat better technically than what we passed before, but its editorial implications appear even more disastrous -- the fact that TARGET dummy arguments sometimes pass identity and sometimes only value makes descriptions of restrictions, behavior, etc. hopelessly unreadable. I still maintain that the correct answer to 000125 should be that identity is transferred only for POINTER dummy arguments. (For convenience, it should be possible to associate TARGET actual arguments with POINTER dummy arguments, just as one can associate constant actual arguments with "variable" dummy arguments.) 125 Y Maine This is a very reluctant "yes." This whole area is a horrible mess. It really needs a complete overhaul. The rules are too complicated for most users to deal with; they certainly are not intuitive. I'm just going to have to advise users to avoid the whole area instead of trying to learn the exact rules. Unfortunately, it is way too late (by 4 or 5 years) to really fix it. We'll just have to live with this as one of the "warts" of the language. --------------------- 000175 What is a "constant specification expression"? 175 Y Bierman Go with Reid 175 N Epstein I prefer the term "integer initialization expression" which does not require a new term to be defined. 175 Y Maine John Reid's explanation is better than the original, which just repeats without explaining. 175 Y Martin John Reid's answer is preferable, but change "need" to "needed" in third sentence. 175 Y North I agree with the comments by John Reid 175 Ywc Reid It would be helpful if the need for this change is explained in the ANSWER. I suggest: ANSWER:A constant specification expression is a specificiation expression that is also a constant expression. An edit is supplied to define this term. The edit is need to make it clear that it is not sufficient for the value of the specification expression to be fixed. For example, if IC is a named constant with value 0 and I is a dummy argument, IC*I always has the value 0, but this is not a constant specification expression. 0175 Y Rolison Additional explanatory material based on the material John Reid suggests would seem to be helpful (it needs a bit of editing). 175 Y Shepherd Use John Reid's version of the answer. --------------------- 000179 DO variable with POINTER attribute 000179 Ywc Barber In edit 2 after R918, insert "[123:30]" 179 Y Bleikamp DO variable with POINTER attribute: If this fails, I hope WG5 lets us fix Fortran 95 to be consistent. 179 N Cohen This interpretation is all wrong. It is attempting to remove a facility which has been in the language for the last 4 years. There is no problem with the facility or its description in the standard (*). It is far too late to be redesigning Fortran 90. (*) Or rather, no problem which is not a problem with all POINTER variables! But I do not think it would be acceptable to delete all POINTER variables from the language; some users might object. > > Note that the DO variable has the POINTER attribute. The POINTER > attribute do not seem to be prohibited for the DO variable, but when the > DO variable has the POINTER attribute, it is unclear as to whether the > DO variable is the pointer the target of the pointer. That is, it is > unclear as to whether the pointer or the target is to be "defined" > (8.1.4.4.1) or incremented (8.1.4.4.2). The above statements are wrong. The standard is perfectly clear - "defining" a pointer variable "defines" the target. Consider the statement PTR = 1 This "defines" the pointer (the language used by the standard!!!). The standard is completely in agreement with itself in thinking that the initial "defining" in DO PTR = 1, 10 is exactly the same as the "defining" of the variable in PTR = 1 To go on, "incrementing" the pointer variable in PTR = PTR + 1 is ***EXACTLY THE SAME*** as what happens in each iteration of DO PTR = 1,10 I note that the only possible confusion arise with certain FORTRAN 77 extensions, also (unfortunately) called POINTER. In the extension to which I am referring, PTR = PTR + 1 does pointer arithmetic, instead of adding 1 to the value of the target! So if we are to delete DO POINTER variables (because of confusion with C or with a certain F77 POINTER extension) we have to forbid "PTR = PTR + 1" as well. > > The standard does not seem to address what happens when the DO variable > is switched to a different variable while the loop is active. Yes the standard DOES say exactly what the situation is: it says that the program in NOT standard-conforming. See page [103:14-15], I quote: "Except for the incrementation of the DO variable that occurs in step (3), the DO variable must neither be redefined nor become undefined while the DO construct is active." Now look at "14.7.5 Events that cause variables to become defined", event (18), [251:9-10], I quote: "(18) Execution of a pointer assignment statement that associates a pointer with a target that is defined causes the pointer to become defined." So "PTR => LCV2" defines PTR, the active DO variable, so is illegal. To consider the other interesting cases, see "14.7.6 Events that cause variables to become undefined", [252:32-33], I quote: "(15) When the association status of a pointer becomes undefined or disassociated (6.3), the pointer becomes undefined." So it is illegal to DEALLLOCATE or NULLIFY the DO variable, and it is also illegal to DEALLOCATE the target out from underneath it because that would also cause it to become undefined. The standard allows a POINTER variable to appear anywhere in an executable statement where its target may appear (e.g. in an expression, on the left-hand side of an assignment statement, as an actual argument). To exclude one case in particular would have made the language unnecessarily irregular, therefore it is clear that the standard DID mean that it was possible for a DO variable to have the POINTER attribute. There is no confusion in the standard about what the examples mean. Indeed, the only people who are confused about what INTEGER, TARGET :: target(10) = (/ (i,i=1,10) /) INTEGER, POINTER :: ptr ptr => target(1) DO ptr=1,10 PRINT *,ptr END DO are the same people who are confused by INTEGER, TARGET :: target(10) = (/ (i,i=1,10) /) INTEGER, POINTER :: ptr ptr => target(1) ptr = 1 DO WHILE (ptr<=10) PRINT *,ptr ptr = ptr + 1 ! In Fortran 90, this is NOT pointer arithmetic ! END DO > EDITS: None are required. It is FAR FAR FAR TOO LATE to be deciding that some feature in the standard might be "bad programming practice" or "confusing if you used another language where similar syntax had different semantics". There are PLENTY of pieces of Fortran language which can be misused or abused. Just ripping out facilities which are in current use (yes, I know people who use this!) is unacceptable. 179 N Epstein See Malcolm Cohen's comments. 179 N Hendrickson I agree with Malcolm Cohen, this is an unnecessary modification to the language, not an error correction. If a change is needed for DO loops surely it is also needed for implied DO's in IO lists, data statements, forall statements, and array constructors. We should also back the change out of Fortran 95; there is no need to add unnecessary restrictions that make the language irregular. The current rule is simple and easy to remember: "A pointer always refers to the actual data thing, except in pointer assignment where it refers to the address thing, and in argument lists where nobody knows what it refers to." 179 Y Hirchert I believe we want to apply these edits, but not for the reasons in Larry's question. It would be nice if the answer indicated that there are more serious problems than the ones Larry points out. 179 N Maine I am convinced by Malcolm's argument that the standard is unambiguous as it stands and that there is no need to change it and invalidate existing code. 179 N Martin This would impose a needless exception - something users abhor. There is no reason to do this. If this item should happen to pass, then text should be added to section 1.5.1 Fortran 90 compatibility. Of course, Fortran 95 should agree with the result of this ballot which means a change either way. Hirchert is correct; the identity of the loop variable should be fixed at the beginning of the loop (as is the loop count). 179 N North I agree with the comments by John Reid 179 N Reid This is an unnecessary technical change to Fortran 90, as explained by Malcolm Cohen. 0179 Y Rolison I will try my darndest to be brief in defending why I think this edit should be made but I do have several points to make so please bear with me. First I would like to address a number of points Malcolm made. I wish that I had had the time to address his comments earlier so that others could have seen my response before they voted, but that's my timing problem, not anyone else's. Malcolm: It is far too late to be redesigning Fortran 90. "Redesigning Fortran 90" I'm afraid is in the eye of the beholder. This change to Fortran 90 in retrospect of its release is no different than many other "changes" we've made to the language over the years up to and including our very old friend Interp 125 which is on this ballot AGAIN. If you were a vendor that implemented any of these interps "the other way" (including 125), then this is a "language redesign" in your opinion. If you are a vendor that implemented your compiler the way a particular interp is answered, then you claim this was what the standard said all along. So to say that we must not change the language now is a null argument. It's been done many, many times via interps. Let's not play favorites here. See also Interp 83 also in this ballot for another example of "redesigning the language". Malcolm: The standard is perfectly clear - "defining" a pointer variable "defines" the target. Consider the statement PTR = 1 This "defines" the pointer (the language used by the standard!!!). The standard is completely in agreement with itself in thinking that the initial "defining" in DO PTR = 1, 10 is exactly the same as the "defining" of the variable in PTR = 1 and Richard Maine: > DO P=1,10 > IF (P==6) P=>K ... Note that the DO variable is P, not its target. Larry: So, indeed, it is NOT perfectly clear. Richard fell EXACTLY into the trap I was afraid naive users were going to fall into and might I say he is a respected member of the committee. This is the crux of my interp request: When a DO variable has the POINTER attribute, is the pointer the DO variable or is the target? And Richard has just proven my case that there IS a question here. It is VERY easy for users to come to the conclusion that the DO variable must be the pointer. Consider: INTEGER, POINTER :: p ALLOCATE(p) DO p = 1, 10 ... END DO Where is the "variable" that is the target? There is none. The only "variable" in sight is the pointer, so therefore it is easy to conclude that the DO variable is the pointer. This is especially easy to conclude, as Malcolm points out, for C users experimenting with Fortran 90 and with Fortran users that are conversant with Cray pointers. Malcolm says: So if we are to delete DO POINTER variables (because of confusion with C or with a certain F77 POINTER extension) we have to forbid "PTR = PTR + 1" as well. to which I respond "Were it up to me, horribly misleading syntax like that would never have gotten into the language." Malcolm's example shows exactly why the pointer implementation in Fortran 90 is such an abysmal failure. We've been arguing about it for 8 years and we're STILL arguing about its syntax and semantics! Had pointers been implemented as a data type, NONE of these questions and confusions would ever have arisen! Anyway, to the point: letting in one miserable bit of syntax is hardly an excuse for letting in more. Malcolm: The standard allows a POINTER variable to appear anywhere in an executable statement where its target may appear... Larry: Not quite true. [124:17-18] of the Fortran 90 states: If a derived type ultimately contains a pointer component, an object of this type must not appear as an input item nor as the result of the evaluation of an output list item. Thus, a component of such a structure can be a target of a pointer ( because the structure is a target), and thus the component can be input/output but a structure containing the pointer itself must not be used as an I/O item. So there is at least one other place where the generalism Malcolm is trying to assert breaks down. We already have one case that makes "the language unnecessarily irregular" so maybe these cases are not so irregular as one might be lead to believe. I do not find Malcolm's arguments persuasive. I do find the almost certain confusion of programmers new to Fortran 90 to be persuasive. This clarification allows the compiler to "teach" them about how Fortran 90 handles pointers rather than finding it out by trying to debug a program based on incorrect language transferral. In spite of some of the original text of the interp being less than optimal, I contend that we should be fixing this oversight in the language and thereby reduce confusion on the part of people trying to learn this language. Kurt's vote also indicates that he would vote for the answer in spite of the original text. I am certainly willing to help draft better examples in the body of the interp to point out why the POINTER attribute should be disallowed. 179 N Shepherd Agree with Malcolm Cohen's position on this restriction. Adding this restriction is not necessary. --------------------- 000198 Characteristics of dummy procedures 198 Y Maine Use John Reid's change to the edit; that is change "and" to "as for" in the first sentence of the edit. Otherwise the edit is ambiguous. I also agree with Henry's suggested change to the first sentence of the discussion. 198 Y Martin John Reid's edit is preferable. 198 Ywc Reid In the last line of the edit, change "and" to "as for". This is better use of English and is clearer. 0198 Y Rolison I agree with Henry that the words "those of" should be removed. This looks like those two words were originally there and then someone tried to clarify what they were referring to by using the phrase "the characteristics of" and just forgot to delete "those of". I'm afraid that John Reid's suggestion as to "better English" may be a mindset difference between the English and American languages. The sentence is clearer to me as is. But I defer to committee grammarians. 198 Y Shepherd 198 Zongaro In the first sentence of "Discussion:", delete the words "those of". The sentence reads a little awkwardly with them. --------------------- 000199 Kind Type Parameters and the DELIM= specifier 199 Y Martin In QUESTION, remove blank before "?". --------------------- 000202 Evaluation of intrinsic procedures 202 Y Bleikamp Evaluation of intrinsic procedures: The question should be broken into two numbered questions. 202 N Barber The discussion does not include a reference to a section in the standard that supports the answer. In the penultimate line of the question insert "if it" after "but" In the first line of the answer insert "in" after "form" 202 N Hendrickson I do not believe the definition of ANINT is an "algorithm. The standard states "...ANINT(A) has the value AINT(A+0.5);...". There only possible reading of this is that the value of ANINT(A) is the same as the value of AINT(A+0.5). What else could those English words mean? If this isn't the meaning we like then we should change the words. The text should be changed to say something like "The value of ANINT(A) is the nearest integer to A after rounding. If the fractional part of A is .5 then the rounding is away from zero." 202 N Hirchert The key to this answer should be that INT(A+0.5) is intended as mathematical description of the rounding intended (i.e., that for example, one must round 1.5 up to 2 and not down to 1), but that it is not a prescription of the specific method by which this mathematical value is to be obtain or approximated. I believe that this key point is not made clear by this wording of the answer. 202 N Martin For reasons given by Janice Shepherd. 0202 N Rolison While I think I agree with the intent of the answer, I'm so unclear as to what the answer is actually saying that I must vote No. First, the answer does not address the question. Let me paraphrase: Question: [If ANINT(16 000 001.0)] can be computed as the more expected 16 000 001.0, may a processor do so? Answer: No, a processor is not bound to use the algorithm form the Standard. Huh? (and I am not counting the obvious misspelling of "from") If the answer is trying to say, "Yes, you can return either 16 000 001.0 or 16 000 002.0" then I agree with it. If, on the other hand, it is saying ANINT must return a certain value in this case, can we really legislate how all machines do internal arithmetic like this, especially where rounding occurs? There are many other places a lot less specific (like REAL for example) where we just say "the result is equal to an processor-dependent approximation to" the input argument. Can we really say here that (A + 0.5) where A is an integral value MUST produce either the next integral value lower or the next one higher? If we're truly at the halfway point, is either integral value really any nearer? 202 N Shepherd The answer specifies no references in the standard. The discussion section indicates that the words in standard have the following intents: - to permit processors to use infinite accuracy if available. - to allow processors to use any mathematically equivalent algorithm the processor desires. What words in the standard indicate these intents? If what is meant is that this is the intent of the committee, then we should at least mention which section of the standard we are interpreting as yielding these permissions. The first sentence of the discussion does not appear to be grammatically correct. In the first sentence of the Answer change "form" to "from" "Standard" is not written with a capital in other defect items.