From janshep@watson.ibm.com Tue Jan 9 17:57:53 1996 Received: from watson.ibm.com (watson.ibm.com [129.34.139.4]) by dkuug.dk (8.6.12/8.6.12) with SMTP id RAA13163 for ; Tue, 9 Jan 1996 17:57:33 +0100 Message-Id: <199601091657.RAA13163@dkuug.dk> Received: from YKTVMV by watson.ibm.com (IBM VM SMTP V2R3) with BSMTP id 1185; Tue, 09 Jan 96 11:57:11 EST Date: Tue, 9 Jan 96 11:57:10 EST From: "Janice C. Shepherd ((914) 784-6313)" X-Addr: J1-K10, Hawthorne 2 tieline 863 To: sc22wg5@dkuug.dk Subject: Results of the 006 ballot Here are the results of the X3J3 006 ballot. I'll post a note once I've updated the 006 files. I'll post a note with the F95 edits using the 95-007r2 page and line numbers. Mallory, please give this a paper number. Miles, your might want to give this a WG5 number. Thanks Janice X3J3/96- To: X3J3 From: Janice C. Shepherd Subject: Results of the post meeting 135 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 and F95 edits 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 or F95 edit 13: 2: 1: P 000027 Requirements for pointer and target association 14: 1: 1: P Fortran 95 edits listed for defect item 27 12: 1: 3: P 000081 Pointer actual argument overlap 13: 0: 3: P Fortran 95 edits listed for defect item 81 14: 1: 1: P 000100 ASSOCIATED intrinsic and zero-sized objects 12: 3: 1: P 000125 Copy in/copy out of target dummy arguments 12: 3: 1: P Fortran 95 edits listed for defect item 125 13: 2: 1: F 000145 Expressions in of a FUNCTION statement 14: 1: 1: F Fortran 95 edits listed for defect item 145 12: 3: 1: P 000148 RANDOM_SEED, RANDOM_NUMBER 15: 1: 0: P Fortran 95 edits listed for defect item 148 12: 4: 0: P 000154 EQUIVALENCE and zero-sized sequences 15: 1: 0: P 000155 Multiple USE statements, rename and only lists. 14: 2: 0: P 000176 Definition of RANDOM_SEED 11: 4: 1: P 000179 DO variable with POINTER attribute 15: 1: 0: P 000183 Unambiguous procedure overloading 14: 1: 1: P 000185 What is the allocation status of an array after an allocation failure? 11: 5: 0: P 000187 TARGET attribute, storage association, and pointer ass. 14: 2: 0: P Fortran 95 edits listed for defect item 187 14: 2: 0: P 000194 Statements between SELECT CASE and CASE 14: 2: 0: F 000196 Inaccessibility of intrinsic procedures 15: 1: 0: F Fortran 95 edits listed for defect item 196 14: 1: 1: P 000201 SELECTED_REAL_KIND result 16: 0: 0: P Fortran 95 edits listed for defect item 201 14: 1: 1: P 000203 Scope of operator/assignment symbols 15: 0: 1: P Fortran 95 edits listed for defect item 203 defect items ------------ items passed: 15 items failed: 2 F95 edits ------------ edits passed: 7 edits failed: 2 A total of 16 votes and 3 sets of comments (John Reid, Willi Schonauer and Michael Hennecke) were received. An item needed MAX(11,10) to pass (2/3 of 16 votes, more than 1/2 of 18 J3 members). So an item needed 11 yes votes to pass. While Henry and I both have comments we only count for one vote. I failed 145 because of the arguments presented by Henry, there was too little support for the sizeable changes proposed to fix the problems raised by Henry. I failed 196 because of the issue raised by Michael about the 2nd edit. I believe the answer to 1b is correct, but I believe the 2nd edit is introducing an error (by not allowing a specific procedure to have the same name as a generic it appears in). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Editorial corrections made to items: 27 Edit 2, change line numbers from [35-36] to [37-38] Instead of changing them to be lists which appears to be a fairly large change, clarify the application of the "not" to the item after the "or" by changing the "or" to "nor" (I verified that 'not ... nor ... ' is used elsewhere in the standard). Edit 3, case (iii) change "are not of size zero or arrays" to "are not of size zero nor arrays" Edit 3, case (v) change "are not of size zero or arrays" to "are not of size zero nor arrays" Change all 'zero sized storage sequences' to 'zero-sized storage sequences' Change the first sentence of the answer to: "The conditions d), e), g), h), i) and j) are sufficient for ASSOCIATED (PTR, TGT) to return a value of .FALSE.. The conditions a), b), c) and d) are such that if any are true, ASSOCIATED (PTR, TGT) is an invalid reference." The common declarations in the example are not valid. Delete the example and the paragraph that introduces the example. F95-27 In cases (ii) and (iii), the last word in each should be in lower case. ie "false" not "FALSE" Edit 2, case (iii) change "are not of size zero or arrays" to "are not of size zero nor arrays" Edit 2, case (v) change "are not of size zero or arrays" to "are not of size zero nor arrays" Change all 'zero sized storage sequences' to 'zero-sized storage sequences' 81 Change the "to" text for edit 3 to: ". If B were declared with the POINTER attribute either of the statements DEALLOCATE (A) or DEALLOCATE (B) would be permitted, but not both." (Jeanne's suggested edit to edit 1, is not applied as the text reads "allocation status" as it is not intended to apply to pointers. Note when a POINTER actual argument is passed to a non-pointer dummy argument, it is the target of the pointer that is the "entity associated with a dummy argument". That target does have an association status.) F95-81 Change the "by" text for edit 4 to: ". If B were declared with the POINTER attribute either of the statements DEALLOCATE (A) or DEALLOCATE (B) would be permitted, but not both." 100 In the discussion, change the 3 "==" to "is equal to" In the discussion, last paragraph, change "matter" to "matter," 125 Change 'is either scalar or is an assumed-shape array' to 'is either a scalar or an assumed-shape array' (3 times: one in last sentence of ANSWER, one in each of edits 2 and 3). F95-125 (95-007r2) [201:1] and in edit 3. Change 'is either scalar or is an assumed-shape array' to 'is either a scalar or an assumed-shape array' Replace edit 4. with: 4. In section C.9.5 [336:32], Change "and is scalar or assumed-shape" to "and is either a scalar or an assumed-shape array" 148 QUESTION 1 and ANSWER 1. Change 'such argumentless calls to RANDOM_SEED' to 'such calls to RANDOM_SEED with no actual argument' ANSWER 2. Change "X2=X3" to "X2 equals X3 after the last call to RANDOM_NUMBER in the example". 154 In ANSWER 1: change "Instead such" to "Such" 155 In the discussion, change "(e.g." to "(e.g.,". 176 In QUESTION, change "Alternately" to "Alternatively" In ANSWER 1, change 'Yes, for GET "TRANSFER" semantics were intended. However the' to 'The' 179 In the discussion, last paragraph change "had contained" to "had contained within the DO construct". change "such as assignment" to "such an assignment". In QUESTION, change last sentence to: "Is it the intent of the standard to permit a DO variable with the POINTER attribute?" 183 QUESTION, first paragraph, Change "The standard considers (14.1.2.3) the following example" to "The following example is considered" Change "because it requires a single" to "because the standard (14.1.2.3) requires a single" QUESTION, penultimate paragraph, Change "are the same:" to "is the same:" Edit 1, line 1 of the new text: change "has" to "must have" 185 In QUESTION, Change "Given a program segment like:" to "Given a program segment such as:" 187 In ANSWER, Change "within a scoping unit but, it fails to do so" to "within a scoping unit, but it fails to do so" Replace the wording of the 2nd edit with: "An object with the TARGET attribute may become storage associated only with another object that has the TARGET attribute and the same type and type parameters." F95-187 Add 2 new edits: Section 5.5.2.3 [70:22] (95-007r2) Change 'shall' to 'may' Section 5.5.2.3 [70:23] (95-007r2) Change 'attribute.' to 'attribute and the same type and type parameters.' 194 ANSWER 1, 2nd paragraph, Change "is introducing" to "introduces" Change "block, and is not trying to" to "block and does not" ANSWER 2. Delete the final sentence. 201 Add a blank after the colon in the section titles (6 times). In QUESTION 1, remove the extra blank ahead of the '?'. Edit section, add another edit (to be the same as F95) In section 13.13.93 [232:7] change "if neither is available" to "if neither is supported" 203 Delete the extra blanks ahead of '?'s (4 times). - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Ballot Comments: Item Yes Who Comment # /No ------------- 000027 Requirements for pointer and target association 27 Y Dedo I disagree with Henry Zongaro's that TARGET variables cannot be storage associated with other TARGET variables that have a different type or KIND. Such storage association is permitted for variables which do NOT have the TARGET attribute. If this ideas became part of the language, we would have another inconsistency. What is so magical about the TARGET attribute that it should prohibit a behavior that is allowed without it? I believe that it would be better to revisit this issue after Fortran 95 is ratified. 27 N Rolison Consider the following program: PROGRAM test INTEGER, TARGET :: tgt(0) INTEGER, POINTER :: ptr(:) ptr => tgt PRINT *, ASSOCIATED(ptr) PRINT *, ASSOCIATED(ptr, tgt) END PROGRAM If Jon and I correctly understand the wording of this interpretation response and that of Interp 100, then we believe this program will output (in general terms) the values "true" and "false". We find this to be unacceptable. We believe the committee should not be in the business of creating trivia questions to include in Fortran 90 programming tests. We don't understand how the committee can seriously respond to this Interp (and 100) with the following: It is the intent of the standard that the two argument form of the ASSOCIATED intrinsic function returns true only if the association of POINTER and TARGET is as if the pointer assignment statement POINTER => TARGET was the last statement executed prior to the execution of the statement invoking the ASSOCIATED function. Is that not what the above program is doing? (The presence of the first PRINT statement is totally irrelevant to the the result produced by the second call to ASSOCIATED.) The "rule of thumb" presented in the response is meaningless. The above program does exactly what the rule of thumb says to do, and yet the first result of ASSOCIATED is true and the second is false. How on earth are we going to explain this to people other than "memorize the rule - there is no reason for its existence". We feel that the easiest and most consistent response to this interp would be to say that zero-sized arrays (or pointers to them) are simply not allowed as arguments to the ASSOCIATED function. If the committee is adamently against that simple concept then the results of the two function calls in the above program should at the very least be the same. Our preferences would be undefined, and if that is not acceptable, then "false". If the committee chooses to go forward with this exceedingly inconsistent definition of ASSOCIATED, then at least please consider the following edits: * The line numbers in the first edit are incorrect. They should be 37-38. * Shouldn't "zero sized" in all the edits be hyphenated? See for example, "zero sized storage sequence" in the first edit. * I find the edits for the array TARGET cases to be difficult to parse and would question whether non-English speakers would filter the "not" referring to zero-sized arrays through both following phrases. I would like to see these cases recast as lists so there is no doubt as to what is being described. I suggest: If TARGET is present and is an array target, the result is true if the target associated with POINTER and the array represented by TARGET: (1) have the same shape, (2) are not of size zero, (3) are not arrays whose elements are zero sized, and (4) occupy the the same storage units in array element order. 27 Y Shepherd The first sentence of the answer needs to be changed to reflect the sense of the edits: "The conditions d), e), g), h), i) and j) are sufficient for ASSOCIATED (PTR, TGT) to return a value of .FALSE.. The conditions a), b), c) and d) are such that if any are true, ASSOCIATED (PTR, TGT) is an invalid reference." Shouldn't "zero sized storage sequences" be "zero-sized storage sequences"? Given Henry's observations, the example and the paragraph introducing the example should both be deleted from the discussion. The rest of the text is sufficient. 27 Zongaro The example program unit in the discussion shows a COMMON block in which a target of type real becomes associated with a target of type complex. Defect item 000160 asked the question "Was it the intent of the committee to allow the storage association of target variables with nontarget variables and variables of different data types?". The states in part, "No, this was not the intent of the standard." My interpretation of this response was that neither was it the intent of the standard that nontarget variables should be storage associated with target variables, nor was it the intent of the standard that target variables of different types should be storage associated. However, the discussion of 000160 does not make it clear whether my interpretation was the intended interpretation, since it only discusses the issue of storage association between target variables and nontarget variables. If my understanding is correct, the common declarations in the example are incorrect. ------------- Fortran 95 edits listed for defect item 27 F95-27 N Rolison (F95 edits) Since we disagree with the direction of the changes for Fortran 90, we must also vote against the edits for Fortran 95. F95-27 Y Shepherd in cases (ii) and (iii), the last word in each should be in lower case. ie "false" not "FALSE" ------------- 000081 Pointer actual argument overlap 81 N Hirchert I object strongly to not applying the overlap restrictions to pointer association status: 1. Even using ideal optimization techniques, this would have a potentially significant performance cost. 2. Given the current state of optimization in Fortran 90 processors, it seems likely that the performance cost will be much higher for the forseeable future. 3. This unnecessary overhead seems especially painful in those cases where pointers were introduced only to force reference (overlap) semantics in the values. 4. I find the example supplied to motivate this change utterly unconvincing. Conceptually, it involved it involved passing arguments to procedure identifying both a linked list and part of that list that was to be modified. We are not willing to pay extra overhead to support this kind of conceptual overlap when the list is stored in an array; I see no reason to pay for it when the list is linked instead. There are plenty of ways to restructure the example to work within the overlap restrictions: a. Separate the procedure into two procedures, one working on the sublist and one working on the entire list. b. Move the logic that located the sublist into the procedure, so that the sublist is not needed as a separate argument. c. Explicitly force reference semantics using pointers. (In this case, this would mean using pointers to pointers.) Given that Fortran's niche is high performance computing, it seems foolish to sacrifice performance to support programmers in poorly structuring their code. As an independent issue, this item reflects much of the worst of what we have done with our approach to item 000125. I find many of the answers and explanations incomprehensible. For example, what does it mean when we say (in answer 3 and other) that allocation status of pointer arguments is restricted but that the pointer association status is not? 81 N Martin These edits are still not quite correct, and if made as is to F95 could lead to a defect report on F95. Edit 1 [Fortran 90] [180:3-4] in the replacement text, delete "status" from the first line. [95-007R1 201:44] extend the edit to delete "status" [95-007R2 203:28] extend the edit to delete "status" Reason: Although pointers may be allocated, they do not have an "allocation status". Note that Edit 2 (F90) [Edit 3 (F95)] uses "allocation" rather than "alloca- tion status" Edit 3 [F90 180:34-35] Edit 4 [95-007R1 202:37-38] [95-007R2 204:20-21] should be replace ", but would ...attribute." with ". If B were declared with the POINTER attribute either of the statements DEALLOCATE (A) or DEALLOCATE (B) would be permitted, but not both." This is required because of statements in 6.3.3.2: [F90 69:23-25] [95-007R1 81:23-25] [95-007R2 83:39-41] "Deallocating a pointer target causes the pointer association status of any other pointer that is associated with the target ... to become undefined." [F90 69:17] [95-007R1 81:17] [95-007R2 83:33] "If a pointer appears in a DEALLOCATE statement, its association status shall be defined." 81 N Rolison I find I must go back to my NO vote from the post-131 ballot and reprise most of the reasoning from that response. I still don't think we've got this right, and far worse, I think the current response changes the language is drastically incorrect ways. Here is an edited version of what I said in the post-131 ballot: It seems to me like the Interp response has gone far afield from what we were trying to find out (and trying to provide to the user). I thought the intent of this Interp response was to allow users to be able to do useful list processing. In many cases, two pointers are passed to a routine and it is unknown whether or not they point at the same node in a list. I thought the response was trying to provide wording to allow a node in the list to be updated by either pointer (and to allow either pointer to get new values in the called procedure). But the examples are all using arrays and come to conclusions that are difficult for me to rationalize. In particular, I'm having trouble with rule (2) at the top of the answer: (2) the values when the dummy argument has the TARGET attribute, is a scalar or an assumed-shape array and does not have the INTENT(IN) attribute and the actual argument is a target other than an array section with a vector subscript, and I don't understand why just because a dummy argument has the TARGET attribute, assigning values to overlapping portions of the dummy arguments is OK. The answer provides the following example of what it intends to allow: INTEGER, POINTER :: IP CALL INNER(IP) CONTAINS SUBROUTINE INNER(IARGT) INTEGER, TARGET :: IARGT IP = 0 ! OK. This alters the value of IARGT, too. First, I don't understand why the example has the actual argument as a pointer when it's attempting to describe a case where the actual argument is a target. Yes, I know, a pointer is also a "target" but the description is about target actual arguments so the actual argument should have the TARGET attribute. If you did this, I think a lot more people would object to this change to the standard. The example would then be: INTEGER, TARGET :: ARRAY(10) CALL INNER(ARRAY(1:5), ARRAY(3:7)) CONTAINS SUBROUTINE INNER(TGT1, TGT2) INTEGER, TARGET :: TGT1(:), TGT2(:) TGT1(3:5) = 0 TGT2(1:3) = -1 The current wording in 12.5.2.9 (which reflects a long standing philosophy in Fortran that you can not define overlapping portions of dummy arguments) would otherwise rule the above example as being invalid. But the words in new rule (2) say that just because ARRAY, TGT1, and TGT2 happen to have the TARGET attribute, assignments to any portions of TGT1 and TGT2 are valid. I just don't understand why the simple addition of the TARGET attribute makes this OK. I think this is wrong, that it destroys a long standing philosophy in Fortran, and therefore this is the first reason I must vote No. -------------------------------------------------------------- The second reason I must vote No is similar. The first example in the Discussion shows a similar case where a pointer is passed as an argument. The example then shows that the VALUE of the dummy argument can be changed via either the pointer inherited from the outer scope or the pointer dummy argument. I believe this also flies in the face of the long standing wording in 12.5.2.9. I understand (I think) what Janice and Henry were trying to get at in the last vote in their example about referencing and changing pointers and values that were not passed into a procedure but I think this fix is wrong and that we should work harder to produce wording that leaves the current philosophy of Fortran intact and yet makes room for pointer usage. I believe that Janice and Henry were citing a case such as this: * Two nodes (structures) of a linked list exist in a procedure. The two nodes may be located (referenced) by two pointers currently associated with them. * This procedure calls another procedure, passing the two pointers. * The called procedure uses the first pointer (which points at the first node) to get to the second node via the link pointer in the first node. A value in the second node is then changed via this indirection. I believe that the thought here is that the current rules do not strictly allow this case because at the time the indirection is done, the pointers "overlap" because they both point at the second node. BUT I contend this is QUITE DIFFERENT than the examples provided. In my example, we reach the second node ONLY via manipulation of a dummy argument pointer. At no time was there a reference using a pointer inherited from the calling procedure AND a dummy argument pointer. Therefore, I believe that we should spend more time to get the wording right such that a user can move a dummy argument pointer all over the place and change values, etc. but ALL pointers must be developed from the dummy argument pointer. This would leave the current expected rules of 12.5.2.9 intact and get rid of the idiocy of the TARGET attribute making some kind of magic happen. We fought out TARGET NOT making magic happen in Interp 125 and finally got that right and now we're letting magic leak back in here. TARGET ONLY ever means that you can get at something via a pointer. It does not and must not add any other characteristics to the object it is being applied to. If we want to add other characteristics (such as "overlap definition is allowed") then we should invent another attribute to say that this is happening. 81 Y Shepherd The instructions for the last edit should be "In section C.12.7, [291:38-42] replace the existing paragraph with :" In the first edit, in item (c) add a "," ahead of the "and" In the sixth edit, in item (c) add a "," ahead of the "and" In the 4th edit change "nor the TARGET" to "nor TARGET" to be consistent with the style in F95. ------------- Fortran 95 edits listed for defect item 81 F95-81 N Hirchert See comments under defect 81. F95-81 N Martin See comments under defect 81. F95-81 N Rolison (F95 edits) Since I'm voting No on the changes for Fortran 90, I must necessarily vote No on the F95 edits as well. ------------- 000100 ASSOCIATED intrinsic and zero-sized objects 100 Y Bleikamp In the discussion, paragraphs 3-5, there are 3 instances of "==", which should be replaced with "equal to" or "was equal to" as appropriate. In the discussion, 6th paragraph, insert a "," after "As a practical matter". In the discussion, 4th paragraph, I think replacing "end case" with "special case" reads better. 100 N Rolison See comments on 27. ------------- 000125 Copy in/copy out of target dummy arguments 125 Ywc Barber I repeat my comment from last time. Incredibly complicated and will baffle the average user. 125 Y Bleikamp The first sentence of the ANSWER should be "Yes.". There are many flaws in the standard, not just "a flaw". The question immediately preceding the question already has the "flaw in the standard" text, so a simple "Yes." is better. nit: last sentence of the answer, delete the last "is", just before "an assumed-shape array". 125 Y Dedo I am still confused as to how the proposed response answers the concerns that Larry Rolison expressed in paper 95-102 and his e-mail message of April 17, 1995. Perhaps the Interpretations Subgroup should prepare an analysis of this issue in the near future. Any of Larry Rolison's concerns which have not been resolved should be addressed as soon as possible. 125 N Hirchert My opposition to our current approach to 000125 is not new, so I'll try to keep this short: 1. Nothing like this was intended when Fortran 90 was originally written. 2. As new language design, it is equally deficient. Instead of providing two different features to supply the two functionalities desired, we have tried to force them into a single feature, with the result that it does neither functionality well. Worse, we have done this in a way that tends to block future extensions to allow these functionalities to be provided well. 3. This latest variation gets the behavior of target dummy arguments "right" in more cases (in my opinion), but makes the dividing line between the two behaviors even more complicated. In my mind, the cost of the latter outweighed the benefit of the former. ------------- Fortran 95 edits listed for defect item 125 F95-125 Y Dedo I agree with Janice Shepherd's proposed edit. F95-125 N Hirchert See comments under 125 125 Y Rolison (F95 edits) Sure, I'll buy Janice's use of the wording in the defect rather than the current wording in the draft. F95-125,Y Shepherd I think the wording in the 3rd line of the defect's 3rd edit "is either scalar or is an assumed-shape array," is better than the wording in 95-007r2 pg 336:32 which is "is scalar or assumed-shape". Thus I would add a new edit to the list of F95 edits: 336:32 section C.9.5, change "is scalar or assumed-shape" to "is either scalar or is an assumed-shape array" ------------- 000145 Expressions in of a FUNCTION statement 145 N Barber It is far side stuff that the fragment module m integer,parameter :: k=4 end integer(k) function f() use m end should be standard conforming whilst the fragment integer(k) function f() integer,parameter :: k=4 end is not. Furthermore if k were a parameter array and the function kind value were k(5) say, then both fragments would be non-standard conforming (since reference before declaration is not allowed for arrays). i.e. use association does not provide access to the same entities in a backwards direction as it does in the forward one. I do not believe it was ever intended that use association operate backwards rather than forwards. If it was then why do use-statements precede all other declarations and specifications? The expressions in a function stmt were an oversight. I think we need some simpler rules for expressions in function statements that prohibit forward references and avoid confusing semantics. If a user really wants to write a function kind or length expression that references an entity in the function specification part it can be done easily in a type specification statement for the function just as is necessary when the function is array valued. 145 Y Bleikamp I like Janice's discussion rewrite for structure constructors, but suggest inserting "derived" as shown below, to clarify what the referenced type is: "A structure constructor can appear in a FUNCTION providing the resulting expression is of type integer and the referenced type is already defined (thus it ^ derived must be accessible by host or use association within the function)." 145 Y Shepherd, The wording in F95 is better for the first edit. Change the "to" part of the first edit to be "in an interface body (12.3.2.1), the specification part of a subprogram, or the of a FUNCTION statement (12.5.2.2)" Given Henry's observations the following changes should be made to the discussion: Replace the paragraph after "* Structure constructor" with "The text from section 7.1.6.1, in (3) of the definition of initialization expression, indicates that a structure constructor where each component is an initialization expression can appear in an initialization expression. The referenced type must already be defined (4.4.4). Therefore for a structure constructor to appear in an initialization expression in the of a FUNCTION statement, the type definition must either be accessible by host association or by use association." Replace the paragraph "A structure constructor can not appear in a FUNCTION ..." with "A structure constructor can appear in a FUNCTION providing the resulting expression is of type integer and the referenced type is already defined (thus it must be accessible by host or use association within the function)." /interp (or some other subgroup) should then decide if wording in 4.4.4 in Fortran 95 should be clarified via an Fortran 95 interpretation. 145 Zongaro The discussion under "* Structure constructor" makes the claim that structure constructors can not appear in a . Later in the discussion, it is stated that structure constructors can not appear in specification expressions in FUNCTION s. Both of these statements are incorrect. For example, I believe the following is valid PROGRAM P TYPE DT INTEGER I END TYPE DT CONTAINS CHARACTER(LEN=SIZE((/DT(1)/)), & & KIND=KIND(SIZE((/DT(1)/)))) FUNCTION F() F = 'X' END FUNCTION F END PROGRAM P assuming that the processor has a character kind type parameter whose value is equal to the kind type parameter of the default integer type. Should the text in 4.4.4 which states "A structure constructor must not appear before the referenced type is defined." be modified to handle use association? ------------- Fortran 95 edits listed for defect item 145 F95-145 N Barber See comments under defect item 145 F95-145 Y Rolison (F95 edits) Why was the first edit not applied to F95? It seems to clarify the sentence to expand "in an interface body" to "contained in an interface body" as well as expanding "in the specification part" to "is contained in the specification part". I prefer that these changes also be made. ------------- 000148 RANDOM_SEED, RANDOM_NUMBER 148 Y Bleikamp I suggest changing "such argumentless calls to RANDOM_SEED" to "such calls to RANDOM_SEED with no actual argument". (or something similar) (in the last sentence of Answer (1)) In answer (2), change the "X2=X3" to "X2 equals X3 after the last call to RANDOM_NUMBER in the example". (or something similar) 148 Y Dedo I agree with Michael Hennecke's concerns about portability. 148 NO Hendrickson The interpretation for part 1 makes no sense. What possible use does the argumentless call to RANDOM_SEED have? The only possible use of the sequence CALL RANDOM_SEED CALL RANDOM_NUMBER(X) ... CALL RANDOM_SEED CALL RANDOM_NUMBER(Y) is to reset the random number generator to a "processor dependent" BUT FIXED initial value. If the intent was to do nothing then there was no need for the argumentless RANDOM_SEED. Given the alternate sequence CALL RANDOM_NUMBER(X) ... CALL RANDOM_NUMBER(Y) under the present interpretation these two sequences produce the same practical results--X and Y don't have any simple correlation. What use is this? The argumentless call was intended to provide a simple portable way to allow people to reset the random number generator without having to allocate an array to hold the seed. With this interpretation there is no PORTABLE way to save/restore the seed without allocating an array at run-time. 148 Y Hennecke Given these questions, I agree with the answers. But the current specifications are still not enough to allow portable use of RANDOM_SEED: 1. The user cannot be sure about the behavior of a PUT call. Although the edit now implicitly assures that a value obtained by GET shall be acceptable as a PUT value, and that the processor is free to modify a PUT value before actually using "something" as a seed, there is still the open question if a processor is also free to _reject_ a PUT value! Since RANDOM_SEED has no mechanism to report such an "error condition" and the standard does neither require that all PUT values (of the correct SIZE) are acceptable nor require the processor to document which values it _does_ accept as a valid PUT input, this is a real problem. Restricting PUT only to restore a former GET value is (now) safe, but a too hard constraint: there may be information that I want to communicate into a generator via PUT, but that it will not necessarily output in a former GET call. 2. The standard leaves it processor-dependent if an argument-less call to RANDOM_SEED does a repeatable or non-repeatable reset. This is what it says (with or without answer 1), but it's still a bad idea: Both variants are sometimes useful, but it's quite disastrous to write a lottery program using a "non-repeatable" processor, move the code to another processor, and end up with a "repeatable" implementation. The best a programmer can do is to include the code from question 1 in the application and then do a PRINT *, "Go and fetch your dice." ; STOP if the result of X==Y is not what he or she expects. Doing non-repeatable resets by PUT if X==Y is true will also be nonportable because of comment 1 above. So the best way would be to require "non-repeatable" semantics; a repeatable reset _can_ be implemented with GET and PUTs. This would change the standard, but as it stands there is no conforming, portable and _useful_ way to use CALL RANDOM_SEED(). More comments on this and some F90 implementations can be found in an article at http://www.uni-karlsruhe.de/~Michael.Hennecke/Publications/#CPC95 000148 Y Hirchert I find the answer to question 1 inadequate. Not only is there no requirement that X and Y be equal, there was the expectation that in a quality implementation, they would probably be different. The purpose of the no-argument form of RANDOM_SEED was to get different random number sequences from different executions. (On the other hand, it was not expected that these executions would occur within a single program execution.) [I note in passing that the original intent of the descriptions of RANDOM and RANDOM_NUMBER in Fortran 90 was to not make requirements out of any of these expectations. In that regard, this item is in conflict with the original intent of the standard.] ------------- Fortran 95 edits listed for defect item 148 F95-148 Y Dedo I agree with Richard Bleikamp's proposed edits. ------------- 000154 EQUIVALENCE and zero-sized sequences 154 Y Bleikamp In answer (1), delete "Instead" (start of 2nd sentence). 154 Y Dedo Is this rule the same as the rule for zero-sized array sections? (I did not have the time to research this question.) 154 Y Hirchert I vote for this item with reluctance. Normally I prefer to avoid special restrictions on degenerate cases, but since we have been unable to agree on the meaning of these cases, restriction seems the only acceptable course of action. 154 Y Rolison I would prefer that the edit read: "Constraint: An that is a substring must not have zero length." ------------- 000155 Multiple USE statements, rename and only lists. 155 Y Zongaro In the discussion, change "(e.g." to "(e.g.,". ------------- 000176 Definition of RANDOM_SEED 176 Y Hennecke See my comments on 148. 176 Y Hirchert Although TRANSFER is one way to map the internal state of the random number generator into a one-dimensional array of integers, I do not believe we should force it as the only method. On some processors, the result of a TRANSFER can cause problems. [Since TRANSFER doesn't show up in the edits, this is really only an objection to the wording of the answer.] 176 Y Martin In QUESTION, "Alternately" -> "Alternatively" ------------- 000179 DO variable with POINTER attribute 179 Y Bleikamp Henry Z's edits are needed. 179 N Hirchert I do not believe it was the committee's intent to allow DO variables with the pointer attribute, but I will accept that aspect of this answer with reluctance. However, I cannot accept the failure to add text to make it clear that the pointer association status of that pointer shall not be changed during the execution of the loop. The derivation of that restriction in the discussion may be technically true, but I think it unreasonable to expect people to come up with it on their own. At a minimum, the derivation of the restriction should have been added to the notes. 179 Y Martin In QUESTION, "Did the standard mean to allow a DO variable to have the POINTER attribute?" -> "Is it the intent of the standard to permit a DO variable with the POINTER attribute?" In Discussion, "such as assignment would also be prohibited because defining the ..." -> "such an assignment would also be prohibited because defining the ..." 179 Y Rolison Much as I still think the response should be "No you can't specify POINTER for the DO variable", the committee has outvoted me so I give up. In order to improve the response as it stands, I agree with Henry's editorial suggestions. 179 Y Zongaro In the discussion, before the line "PRT = 10", change "had contained" to "had contained within the DO construct". In the line after "PRT = 10", change "such as assignment" to "such an assignment". ------------- 000183 Unambiguous procedure overloading 183 Y Martin QUESTION: Replace with "The following example is considered to be ambiguous: INTERFACE BAD ... END INTERFACE ! BAD because the standard (14.1.2.3) requires a single argument ..." Further in QUESTION, "A third example ... where the number ... are ..." -> "A third example ... where the number ... is ...". 183 Ywc Reid Edit 1, line 1 of the new text: change "has" to "must have". ------------- 000185 What is the allocation status of an array after an allocation failure? 185 N Barber I do not disagree with the answers but I do not believe they are readily discernible from the standard. Edits to 6.3.1 and 6.3.3 need to be made to make the error semantics of allocation and deallocation lists explicit. 185 Y Martin In QUESTION, "Given a program segment like:" -> "Given a program segment such as:" ------------- 000187 TARGET attribute, storage association, and pointer ass. 187 Y Bleikamp Both the original and Henry's proposed edit (2) are phrased in the affirmative (must ... only ...). Shouldn't this be phrased as "must not ... unless ...."? Otherwise, one could (perversely) read it as REQUIRING all objects with the POINTER attribute to be storage associated with another object. 187 Y Dedo I disagree with Henry Zongaro's comments and proposed edit. If they are approved, they would introduce another inconsistency into Fortran. (See comments on defect item 27.) With this interpretation, a program could have different names with the TARGET attribute via different COMMON definitions but could NOT have different names with the TARGET attribute via EQUIVALENCE. This is a weird inconsistency. Should we remove or modify the constraint that was added in defect item 160? 187 Y Martin In ANSWER, "within a scoping unit but, it fails to do so" -> "within a scoping unit, but it fails to do so" 187 Y Rolison I sympathize with Rich Bleikamp's comments about the wording Henry proposes for the second edit. I suggest just changing the word "must" to "may". I believe we use "may" in a number of places in the standard to mean "we allow this" as opposed to "we require this". 187 Y Shepherd Given the wording in defect 160, I agree with Henry that the edit should be changed to his proposed wording. A similar change should be made to F95; see below. 187 Y Zongaro Referring to the comments on defect item 27, above, should the second edit be changed to the following? "An object with the TARGET attribute must become storage associated only with another object that has the TARGET attribute and the same type and type parameters." ------------- Fortran 95 edits listed for defect item 187 F95-187 Y Rolison (F95 edits) Same comment as above. F95-187 Y Shepherd Make the same change as per the 2nd edit of 187. The text of the 2nd edit was already part of F95. (Using 95-007r2 page/line numbers) Section 5.5.2.3 [70:23], change "attribute." to "attribute and the same type and type parameters." ------------- 000194 Statements between SELECT CASE and CASE 194 Y Hirchert I still believe that it was not the committee's intention to create this one odd place where FORMAT and DATA could not appear, but I will accept that aspect with reluctance. I am less than happy with the statement of the answer to the second question. The final sentence in the paragraph, although literally true, borders on being misleading, as it tends to obscure the point that INCLUDE lines and the statement BNF are orthogonal. 194 Y Martin In the ANSWER for 1, "The sentence in 8.1 [95:12] that defines a block in prose is introducing the general concept of a block, and is not trying to precisely define the BNF term." -> "The sentence in 8.1 [95:12] that defines a block in prose introduces the general concept of a block and does not precisely define the BNF term." ------------- 000196 Inaccessibility of intrinsic procedures 196 Ywc Barber After the program fragment in the question insert the text "any reference to function SIN in subroutine SUB refers to the internal function SIN, not to the intrinsic function of the same name" This completes the sentence preceding the fragment that otherwise is left dangling. 196 N Hennecke I agree with the answer to (2), and edit 1. I do not agree with the answer to (1b), and edit 2 which was made to justify that answer is inadequate: The 3rd paragraph of 14.1.2 originally reads "in the case of generic names (12.3.2.1)". The last paragraph of the quoted section 12.3.2.1 contains the sentence "A generic name may be the same as any one of the procedure names in the interface block, or the same as any accessible generic name." Edit 2 introduces a restriction to the second half ("when both are generic names"). This is a change of the original meaning of 14.1.2, which (in my opinion) addresses the possibility of the first half of the above quotation from 12.3.2.1. If accepted, edit 2 would invalidate the use of a name both as a generic identifier and as the name of a specific procedure in that interface block. Edit 2 should be withdrawn or modified to include the case of "a name used as a generic identifier and as the name of a specific procedure in that interface block". This does not always prohibit the appearance of an "INTRINSIC SIN" stmt, there are a few more holes. I'd prefer to delete the "..." line in [007r1,272:10] and defer that discussion to a F95-interp. 196 Y Hirchert I took special care in looking at the answer to 1b in light of the Hennecke response, but I could find nothing wrong with the answer. [To amplify on that answer, a name is allowed to be both generic and specific in a scoping unit only if the specific is part of the generic, and this was not the case in 1b.] ------------- Fortran 95 edits listed for defect item 196 F95-196 N Hennecke See my 196 comment. F95-196 Y Hirchert See comments under defect item 196 ------------- 000201 SELECTED_REAL_KIND result 201 Ywc Barber The third edit as supplied in f95 is missing in the f90 version In section 13.13.93 [232:7] change "if neither is available" to "if neither is supported" 201 Y Hennecke Why do the F95 edits have an edit 3 not applied to F90? 201 N Martin The punctuation is strange. A blank should follow the colon (:) in 6 places. In Question 1, the blank before the question mark (?) should be deleted. More seriously, the third edit (that appears in the edits for F95 is missing from the defect response. ------------- Fortran 95 edits listed for defect item 201 F95-201 Y Hennecke See my 201 comment. ------------- 000203 Scope of operator/assignment symbols 203 N Hirchert It seems to me that operators should be analogous to function names. Just as "SIN" is called a local name for an intrinsic function, "*" should also be a local "name" for an intrinsic function. The fact that you can potentially access that in any scoping unit should no more make "*" global than it does "SIN". [If operator symbols are local, just like names, the issues in the original question become moot.] 203 Y Martin In QUESTIONs, the blanks before question marks should be deleted (4 times). ------------- Fortran 95 edits listed for defect item 203 F95-203 N Hirchert see comments under defect item