J3/02-253r1 To: J3 From: Dick Hendrickson Subject: Typos In The 007-R2 Draft Date: 15 August, 2002 JOR responses to most items, including edits, is in paper 02-259R1. Responses to other comments, including some edits, are in this paper. Note: edits are marked JOR: EDIT after the question, items with just a response and no edit are marked JOR: Page Line Comment 17 13-14 What is a subobject of a constant considered to be? I think it should say that it is an expression which may or may not be a constant expression, depending on whether the selector is a constant or not. Or should it be an initialization expression? There appears to be an issues here, including 128:27 which says that a subobject of a constant is an initialization expression, presumably allowing string(n:n), where n is a variable. For example: character(*), parameter :: string = 'abcdefg' type point real x, y end type type(point), parameter :: origin = point(0.0,0.0) We believe origin%x is a constant expression whereas string(I:J) is is a non-constant expression when I and J are variables, which at least 128:27 thinks is an initialization expression. The text should say what it is (if it is not stated someplace or not implied) or as a note if it is implied by the syntax rules and appropriate definitions. JOR: We don't think it's a problem, within initialization expressions the substring selectors, etc, are limited themselves to initialization expressions. 33 18 Is the reference 4.5.1.5 correct? Section 4.5.1.5 seems to have nothing to do with a subroutine and generic interface with the generic specifier "ASSIGNMENT(=)". Can a type bound proc redefine assignment? If so, maybe that is why the reference is here. (We just don't know.) JOR: EDIT 33:18, 61:9, 124:4, 124:13, 124:32, 144:6, 144:14, 418:12 change "4.5.1.5" to "4.5.1" 43 14-16 This appears wrong as it appears to be making the assumption that a subobject of a constant is a constant. For example, suppose NAME is a named constant array and I is a type-param-name and consider name(I:I) as a type-param-value in a data-component-def-stmt somewhere. This is allowed but it is a surprise and bizarre. It is possibly based on the misunderstanding (a very "slippery slope") that a subobject of a constant is a constant. JOR: No, the constraint applies to the expression, not just the top level terms. So an expression like constant_array(I_variable) is disallowed because it contains a reference to a nonconstant (the I_variable). 65 20 The concept of a type that is "compatible" with intrinsic assignment seems to mixing up this concept (or confusing me at least) with the concept "type conformance in intrinsic assignment". You have defined "compatible types" in the polymorphic sense but this is not that concept here. The text of Section 7 refers to the concept of type conformance, which I believe is the correct term. Therefore, change "compatible with intrinsic assignment to" to "in intrinsic assignment type conformance with". (Also, compare with p. 90, lines 29-32 where the word compatible is used where conformance should probably be used.) JOR: EDIT 65:20 Change "compatible with intrinsic assignment to" to "in type conformance with" 96 Section 5.4 Either as a note (because you think it is implied somehow or stated someplace but where) or as a forgotten but intended restriction, you should state that a named data object cannot be in the same namelist group more than once. The issue is not clear (unless it is stated someplace that I cannot find) because the list is like an I/O list for which you can repeat items. On the other hand, it is like a declaration (because it appears in the specification part) where the assumption is that a named object is not declared twice. I recommend that you add the following sentence (or a note here) after "group" on line 18, page 96: "A named data object must not be in in the same namelist group more than once." This may have been the discussion of an interp that allows repeats here, and if so, should be stated as a NOTE. JOR: The interp allowed repeated use of the name. There is no need to state it here, since without a prohibition it is allowed. 97 33 Insert "sequenced" before "derived type". This certainly helps comprehend what this restriction is saying but it does not have the intended meaning if constraint C584 is not part of the interpretation. It is thus redundant, but "sequenced" is a very helpful adjective in this sentence. JOR: EDIT 97:33 Insert "sequence" before "derived type" 109 19/21 Last sentence: this is only two of other prohibited appearances of a many-one array section in a context in which the section can become defined (for example, one other way is when many-one array section is an actual argument corresponding to a dummy argument that has intent(INOUT) or intent(OUT), or a dummy argument that is defined, or as an internal file, and so on). I recommended that the sentence be modified as follows: "A many-one array section shall not appear in any context in which the many-one array section can be defined, such as on the left of an equals sign in an assignment statement, as in an input item in a READ statement, or as an actual argument associated with a dummy argument that can become becomes ??defined or undefined.". JOR: EDIT 109:19-21 Replace sentence with "A many-one array section shall not appear in any context in which the many-one array section can be defined or undefined, such as on the left of an equals sign in an assignment statement, as in an input item in a READ statement, or as an actual argument associated with a dummy argument that becomes defined or undefined." 113 NOTE 6.19 appears out of place because it explains the text on lines 1-3 of page 116 in a different section. I recommend it be located in Section 6.3.3.1 after the quoted text. JOR: EDIT 113:NOTE 6.19 Move to 116:3+ 126 4-6 This list is not complete. What about other places which do not seem to be covered such as in an item in the I/O list of a READ statement, as the only primary which is an item in the I/O list of a PRINT or WRITE statement, and as an actual argument corresponding to a non-pointer dummy argument (there are probably lots more places). JOR: Yes, but this is a list of how things are used in expressions. The other cases are covered in the appropriate places. 128 NOTE 7.9: Where is the prohibition against recursion for a specification function? It does not appear in the above. If it has been left out, then reinstate it here. If it is somewhere else, then have the note refer where the restriction is stated. JOR: The restriction was deliberately removed for F2K. 17 4-7 This seems to be a change in what a local variable is? JOR: Change from what? F95 only had the definition of variable in this section. This definition appears to be correct for "local". 33 1-4 How is passing a value via an assumed-type parameter different than argument association? JOR: Assumed values are passed by hidden dope vectors, the user doesn't have anything associated directly with them. They can't be changed in the program as normal arguments can be. 86 NOTE 5.23 What does "starts from" mean? JOR: Probably a poor word, do you have a better suggestion for an informal note. It basically means the first part-ref in the thing it points to. 93 1-5 What is the difference between the name of a procedure pointer and a proc-entity-name? JOR: We needed a BNF term, not an English language term. Also, proc-entity-name is any procedure name, not just pointer things. 96 Section 5.4 Can a named data object appear more than once in a NAMELIST group, either in the same statement or in different statements with the same namelist group name? JOR: Yes, it can, there was an F95 interp about this. 105 9-11 Why the second sentence of this constraint? JOR: Without it you could create ragged arrays by having each allocated thing be of different size 105 15-18 Why is this distinction necessary? See also NOTE 6.4 JOR: Has to do with pointer assignment If A is a thingo, B and C are normal component things, and P is a pointer component thing, then A%B%P = 1 doesn't change anything in A (it changes something off in the weeds). But A%B%P => target actually changes something in A. Whereas A%P%C = 1 never changes anything in A, it always points off into the weeds 114 26-27 How is it possible to do this? With polymorphic objects somehow or is there some direct way? JOR: A monomorphic example would be Type xx Real, pointer :: y(:)) End type Type(xx), allocatable :: a(:) Integer, pointer :: II(:) ... nullify ( A(II(7))%y, II) 115 9-11 How is it possible to do this? With polymorphic objects somehow or is there some direct way? JOR: Same as previous example, with deallocate (and II allocatable) 116 16 Why does this not include a pointer subobject? Maybe because a pointer have created an object that is also a target and automatic deallocation may not be expected or desirable? Can an allocated object be a target in which case the same situation can occur. JOR: Because a pointer subobject can point to something that it didn't create. For example, Allocate (A,B) A%P => III B%P => III Deallocate (A) Would cause B%P to be a dangling pointer if the subobjects were magically deallocated. A garbage collector could do it, but it would need a usage count or however those things work. 119 24 Why is a type-param-name not a designator? JOR: Because its use is so limited that if it were included in the term "designator" then there would have to be an exclusion almost everywhere the term designator was used.