From lrr@ironwood.cray.com Tue Apr 19 03:27:54 1994 Received: from cray.com (timbuk.cray.com) by dkuug.dk with SMTP id AA28319 (5.65c8/IDA-1.4.4j for ); Tue, 19 Apr 1994 15:28:12 +0200 Received: from sdiv.cray.com (ironwood.cray.com) by cray.com (Bob mailer 1.2) id AA29504; Tue, 19 Apr 94 08:27:57 CDT Received: from hickory317 by sdiv.cray.com (5.0/CRI-5.14 Sdiv) id AA03505; Tue, 19 Apr 1994 08:27:56 +0600 From: lrr@ironwood.cray.com (Larry Rolison) Received: by hickory317 (5.0/btd-b2) id AA05605; Tue, 19 Apr 1994 08:27:55 +0600 Message-Id: <9404191327.AA05605@hickory317> Subject: Larry's corrigendum ballot To: sc22wg5@dkuug.dk Date: Tue, 19 Apr 1994 08:27:54 -0500 (CDT) X-Mailer: ELM [version 2.4 PL23] Content-Type: text Content-Length: 22243 X-Charset: ASCII X-Char-Esc: 29 Here's my ballot in case anyone is interested. I hope my NO votes change a few of your minds... ==== WG5 informal letter ballot on N965 items.....closing date Apr 18, 1994 ==== The titles of the 49 items are listed below, "Y" indicates the "Yes" column (without comments), "wc" next to "Y" represents the "Yes-with-comments" column, and "N" indicates the "No" column. Comments or reasons may be inserted after each item. Y|wc N N865 Item |X|_| |_| 000000b Minor edits and corrections to ISO/IEC 1539:1991 (E) |X|_| |_| 000004 Blanks in format specifications in free source form |X|_| |_| 000011 Multiple accessible defined operator and assignment interfaces |_|X| |_| 000029 Class of a defined operator |_|X| |_| 000030 Length of character literals in array constructors |X|_| |_| 000033 Interface blocks with the same name in a program |X|_| |_| 000039 Association of a pointer actual argument with a dummy argument |_|_| |X| 000054 Resolving generic procedure references |_|X| |_| 000058 Ambiguous use of "keyword" |X|_| |_| 000071 Use association and common block names |X|_| |_| 000073 Description of the MERGE intrinsic function |_|X| |_| 000075 Interface blocks in block data |X|_| |_| 000076 Attributes, properties, characteristics |X|_| |_| 000077 Miscellaneous questions |_|X| |_| 000082 Host association and generic names |X|_| |_| 000087 PARAMETER statements and SAVE statements |X|_| |_| 000089 Errors in the DATA statement description |_|_| |X| 000092 Pointer and storage association |_|X| |_| 000093 Scalar pointer function results |_|X| |_| 000097 Specification expression |X|_| |_| 000099 Generic interfaces |X|_| |_| 000100 ASSOCIATED intrinsic and zero-sized objects |X|_| |_| 000102 Returned value for INQUIRE POSITION= on an empty file |_|X| |_| 000105 Parallel evaluation of operands and arguments |_|_| |X| 000106 Multiple USE of modules; renaming rules |X|_| |_| 000108 Referencing disassociated pointers |X|_| |_| 000111 Array constructors in masked assignment statements |X|_| |_| 000112 Sequence derived type external functions |X|_| |_| 000113 Ordering of array specification and initialization |X|_| |_| 000116 Scoping units and statement labels |X|_| |_| 000117 Use of MODULE PROCEDURE statement in internal procedures |_|X| |_| 000123 Result of INT(A) not equal to A for non-default integers |X|_| |_| 000124 Result of LBOUND for assumed-size arrays |X|_| |_| 000126 Character Entry statements and Partial Association |X|_| |_| 000127 Is a module a global entity? |_|X| |_| 000128 Use associated generic names and renaming |_|_| |X| 000129 Array constructors in initialization expressions |_|_| |X| 000130 Multiple statements on line with END statement |X|_| |_| 000131 Formatted Input and Kind Type Parameters |X|_| |_| 000132 SYSTEM_CLOCK intrinsic conformance requirements |X|_| |_| 000133 Definition of RtokenS as used in section 3.3.1 |_|_| |X| 000144 Specification expressions and implicit typing. |X|_| |_| 000150 Undefinition of implied-DO variables in I/O statements |_|_| |X| 000151 Defined Operators with POINTER Operands |X|_| |_| 000152 Processor dependent values for list and namelist directed output |X|_| |_| 000153 Defined Operations, dummy arguments INTENT(IN) |X|_| |_| 000155 Multiple USE statements, rename and only lists. |X|_| |_| 000157 LBOUND and UBOUND return values |X|_| |_| 000170 Argument Keywords and Intrinsic Procedures 29 Y Rolison Nit: "defined-operator" in the ANSWER should be "" to indicate it is in italics and is a metaterm. 30 Y Rolison Since the QUESTION uses the editorial convention of angle brackets surrounding metaterms, the ANSWER should, too. 54 N Rolison I repeat my response to this item from a previous X3J3 ballot: Actually, we'd prefer to respond to this one as "NO, NO, a thousand times NO". The example is not standard conforming. You can not override an intrinsic procedure name when it has an argument as specified in its definition any more than you can override an intrinsic operator name for operands types for which it is defined. Therefore, the response is moot. 58 Y Rolison The second phrase ("keyword arguments") in edit 10 is wrong. The standard contains the phrase "argument keywords" in this location. 75 Y Rolison I repeat my comments essentially verbatim from the X3J3 ballot on this item: The quote from the standard should be terminated by a period (inside the closing quotation mark). We generally use angle brackets to indicate italic font so "interface-block" in the quote from the standard should be "". The answer is a bit abrupt. Yes, the original questioner is a committee member but these responses may be read by many nonmembers and should be geared toward them. I would prefer a response that addressed the question a bit more directly and diplomatically. Perhaps: The syntax rules for include which in turn includes . Although the constraint is redundant with the second constraint of 11.4, we felt there was no harm in leaving this constraint intact as a reminder that an interface block must not appear in a block data subprogram. 82 Y Rolison It appears that X3J3 tried to respond to my editorial comments in its ballot on this item but got the editorial changes wrong. The second sentence of the question is repeated in the first phrase of the third sentence. Delete the second sentence (the one beginning "Thus F is the name...". 92 N Rolison The answer claims that the example it provides is not standard conforming but cites no text proving the case. I contend that reason no text was cited was that THERE IS NO TEXT that supports the answer. The answer might well be what we want (in fact I agree with the SPIRIT of the answer) but the technical basis of the answer is flawed because it does not cite any definitive text in the standard. The following sentences from C.5.3 (page 269) of Annex C (NOT part of the standard) is sometimes quoted as support for the answer: [The TARGET attribute} allows the processor to assume that any nonpointer object not explicitly declared as a target may be referred to only by way of its original declared name. The rule in 5.1.2.8 ensures that this is true even if the object is in a common block and the corresponding object in the same common block in another program unit has the TARGET attribute. The "rule" being cited in 5.1.2.8 is: An object without the TARGET or POINTER attribute must not have an accessible pointer associated with it. How does this purport to provide the insurance mentioned in Annex C? I don't think the sentence in question produces the claimed insurance at all (or at least that was not the intent). I think it's there to clarify the "may" in the first sentence of 5.1.2.8. That is, it's just reiterating that you can't do the following: INTEGER i INTEGER, POINTER :: p p => i There is no way that a pointer can become pointer associated with an object that does not have the TARGET attribute. There is nothing in sections 7, 14, etc. that allows this and all kinds of words that say a pointer can not be pointer associated with an object unless that object has the TARGET attribute. There is pointer association and there is storage association but pointer association does not "transmit" through storage association. The cited sentence is trying to stop something that does not exist in the standard! However, I know that it exists in real life. Example: INTEGER i, j TARGET i EQUIVALENCE (i, j) INTEGER, POINTER :: p p => i IF (ASSOCIATED(p,j)) THEN PRINT *, "Associated" ELSE PRINT *, "Not associated" END IF END Pointer P is ONLY pointer associated with object I; since object J does not have the TARGET attribute, it is impossible by the way the standard is written for pointer P to be pointer associated with object J. You can't even execute the ASSOCIATED function as shown because J has neither the POINTER nor the TARGET attribute. Therefore, the sentence in 5.1.2.8 does nothing to stop what we want it to stop. I think the sentence is bogus and needs to be changed to something like An object without the TARGET or POINTER attribute must not be {storage, name, ?} associated with another object that has an accessible pointer associated with it. This at least uses concepts contained in the standard. Also note that my above example purposely uses the EQUIVALENCE statement. X3J3 is already considering another interpretation request regarding what happens when an object with the TARGET attribute is contained in an EQUIVALENCE list with other objects that do NOT have the TARGET attribute. If the sentence in 5.1.2.8 exists to prevent the common block case, then surely it must exist to prevent the EQUIVALENCE case but in reality it prevents NEITHER! Thus, we have yet to decide whether or not an EQUIVALENCE list can contain mixed targets and nontargets or whether targets should be allowed in EQUIVALENCE lists at all. If the committee would add a sentence such as I suggest above, it would take care of both cases. 93 Y Rolison I repeat several of my comments from the X3J3 ballot. These items are still wrong: In QUESTION, change "pointer attribute" to "POINTER attribute". In Discussion, change "5.2" to "5.1" (5.2 is "Attribute specification statements", not "Type declaration statements"). Note that the edit itself mentions section 5.1, not 5.2. The new location of the paragraph as specified in the edit seems to be a bit strange in that it doesn't seem to relate to any text around it. I am not even sure that adding the paragraph is necessary since 12.2.2 states quite clearly "The characteristics of a function result are its type, type parameters (if any), rank, and whether it is a pointer." Just removing the sentence from section 5 would be enough because the reader would no longer think that the result had to be an array pointer. Thus, I would prefer that the edit consist of just the deletion of the sentence in section 5. If you do not accept this suggestion, at least correct "pointer attribute" to "POINTER attribute" in the new paragraph. 97 Y Rolison The edits in this RFI change exactly some of the same text as the edits in RFI 47. RFI 47 has already been balloted and passed by WG5 and is ready for SC22. What happens to RFI 47? How can SC22 vote on conflicting editorial changes? Doesn't WG5 need to ballot to remove RFI 47 or at least vote to have it officially subsumed by 97? 105 Y Rolison The sentence "Any program whose results depend on how expression evaluation is performed is not standard conforming." paints with an awfully wide brush. I dare say that I depend on a processor to perform the multiplication in the following assignment statement before the addition in order to provide correct results: a = b + c * d and I hardly think this dependence renders this fragment (and its containing program) to be not standard conforming. 106 N Rolison I essentially repeat my comment from an X3J3 ballot on this item: We believe that the previous draft response was the correct response. (It essentially stated that if one USE statement referring to a given module had an ONLY clause, all such USE statements must have an ONLY clause.) One particularly annoying segment of the response is: There are programming practices that can minimize the confusion this might engender: Use of multiple USE statements referencing the same module can be limited to those cases where it is required by the length of the list involved. A programming language standard should not rely on a convention locally adopted by a particular group of programmers to "minimize the confusion this might engender". Minimizing confusion is one of the duties of a standard. If we think this is a bad idea and leads to confusion, then don't allow it. 123 Y Rolison I repeat my editorial comments from a previous X3J3 ballot on this item: Everywhere in this interpretation request, do NOT hyphenate "non-default". In the QUESTION, change the quote from the standard so that it reflects the text in the standard; change "case" to "Case", change "type INTEGER" to "type integer", and complete the quote with a period. Also change "INTEGER kind" to "integer kind". 128 Y Rolison I reluctantly vote Yes with the same reluctance I expressed when voting on this item in a previous X3J3 ballot: I will vote Yes on this but I must say that I am disheartened that in this case the LOCAL name is chosen but in (passed) interpretation 20, the name in the module is the one that has precedence. I would greatly prefer that there be one overriding rule; when something is renamed, the local name is always used for such resolutions, or when something is renamed, the name in the module is used for such resolutions, but NOT a mixture of the two rules. I like the axiom that the fewer rules there are to remember, the better it is and I think this is a good place to apply the rule. 129 N Rolison Nit: Near the end of QUESTION, the phrase "ABS(I)U" appears. I suspect that this was formerly ' "ABS(I)" ' as is found in other places in the text of the RFI. In a previous X3J3 ballot, I voted Yes on this item even though I personally would have voted NO. The reasons for the apparent conflict are unimportant. However, we have learned much over the last year so this time I'm voting NO. There are two examples that the interpretation question provides that point how exactly how ludicrous the current response is: INTEGER, PARAMETER :: array = (/ ABS(-3), ABS(-2), ABS(-1) /) is valid but INTEGER, PARAMETER :: array = (/ (ABS(i), i = -3, -1) /) is not. This is ridiculous language design. The reasoning given in the response is incorrect because it begins with the wrong rule in 7.1.6.1. The correct starting rule is rule (2) of 7.1.6.1 at the bottom of page 77. I reiterate: An array constructor where each element and the bounds and strides of each implied-DO are expressions whose primaries are EITHER initialization expressions OR IMPLIED-DO VARIABLES, (emphasis mine). Therefore, the answer should be: Yes, the fragment is standard conforming. In the fragment PARAMETER (ARRAY = (/ (ABS(I), I = -3, -1) /) and considering 7.1.6.1, second list, rule (2) ABS(I) is an element of the array constructor. It is an expression consisting of exactly one primary, a function reference. That function reference has one argument, I, which is an implied-DO variable. Thus, the expression ABS(I) meets the requirements of rule (2). The overriding language design consideration here should be that an initialization expression is one that can be calculated at compile time. ABS(I) in an implied-DO is just as calculatable as ABS(-1) so there is no reason to prevent it (and lots of reasons to allow it). I contend the wording of rule (2) already (correctly) allows this case. 130 N Rolison I continue to vote NO on this item for the same reasons I've voted NO on it on at least two other ballots: Loren Meissner summarized this issue quite succinctly in an e-mail message: I think the whole thing is a bit messy, and restrictions on the END statement should be minimized insofar as possible. I thought it got into F77 (or earlier) because of the ineffective technology of the day. Can't we do better nowadays? No competent compiler will get it wrong (and if one does, let the marketplace decide...). Why is this a problem? The typo case cited is hardly an overriding reason for having this rule in the language. Think of the wasted effort by every robust compiler that must (a) look for a semicolon following the keyword END (but only when it's ending a program unit), and then (b) look beyond the semicolon to see if another statement actually exists on the line and, if so, issue an error message. If this rule goes in, many compilers will likey extend the standard to allow text following the END so it means that all these compilers will have to waste time at each and every program unit END to check to see if it's followed by a semicolon and if so, issue a nonstandard usage message. I repeat Loren's comment: Can't we do better nowadays? Hasn't compiler technology advanced beyond this? Why are we saddling all the compilers that can handle statements following the END statement with the ancient baggage of compilers that can not? 144 N Rolison I repeat my reasoning from a previous X3J3 ballot on this item: The first sentence of the Discussion is completely irrelevant. I know there was some discussion at the Brussels meeting that these two cases could be differentiated on the basis that COMMON statements must occur by the end of the specification statements and DATA statements need not. Therefore, it was reasoned, a compiler COULD stop at the first executable statement and do all specification statement processing and then resume executable statement processing. Well, yes, a compiler COULD do that but I'd hate for the committee to MANDATE it via the standard. Some argued that the DATA case is "much harder" because a compiler would have to "backpatch" all the places in the executable internal representation when it discovered that the initialized item was actually a local item and not host associated. Well, the example presented in the interpretation request is necessarily simple, but you could just as well have a program that has 500 lines of specification statements that use the common block member hundreds of times and then discover the COMMON statement. Allowing the forward reference to the common block member is bad language design both for a compiler (because it now introduces a whole bunch more places where it can not "lock in" to a name from the host) and for a user because the larger the specification section becomes and the lower the common block declaration, the more misleading the program will be. People tend (rightfully so, given today's atmosphere of computer "science") to look UP for declarative information, not DOWN. So, this forward reference is unnecessary and bad for both compilers and program readers. The correct response is to institute a rule similar to the DATA rule for COMMON statements. 151 N Rolison I repeat my reasoning from a previous X3J3 ballot on this item: This is probably a futile gesture but I'm voting No because I think this is just plain silly. The reason that the INTENT attribute is not allowed for pointers is that some committee members maintained long ago when this first came up during a public review that we couldn't tell whether INTENT applied to the pointer or to the target of the pointer. This is the part that's really the silly part: we (the committee) ARE the Supreme Court of this language; WE design this language; WE are the ones that SAY what INTENT for a pointer dummy argument means. How can the committee possibly say with a straigth face that we don't know what it means? Just pick a meaning and go with it. I would prefer that it apply to the pointer. ------------------------------------------------------------------------------ Larry Rolison lrr@cray.com Cray Research, Inc. 655F Lone Oak Drive Eagan, MN 55121 ------------------------------------------------------------------------------