J3/01-283 Date: August 4, 2001 To: J3 From: Dick Hendrickson Subject: Chapter 7 comments 1) Page 107, Note 7.1, 7.2, and 7.3. These don't add anything to the text and should be deleted. 2) Page 113, 7.1.4.1. First paragraph. We should add type-param-inquiry and type-param-name to the list to be parallel with R701. 3) Page 113, 7.1.4.1, paragraph after bulleted list. the last sentence appears to rule out a disassociated pointer as the second argument to ASSOCIATED, yet associated only requires not undefined. 4) Page 114, 7.1.6. Why do we use the term "restricted expression"? The only use of "restricted" that I found were in 7.1.6 and there we say a specification expression must be a restricted expression. Wouldn't the section read better if we replaced all references to "restricted" by "specification"? See the initialization section following this one. 5) Page 114, 7.1.6, bullet (8) Is "other standard intrinsic" the right term. The "other" is sort of dangling. I think this is a holdover from F95 where (7) had a list of inquiry functions. I think "standard intrinsic that is not used as a specification inquiry" might work 6) Page 114, 7.1.6. (5) and (11) seem somewhat redundant 7) Page 115, note 7.12, last sentence. I believe specification functions can be recursive. It's that they can't invoke the current procedure. Change "recursion" to "self recursion". 8) Page 115, 2 paragraphs after note 7.12. Are these going to be changed due to an interp about what previous means? If not, they are unclear. 9) Page 116, 7.1.7. I'd copy the first sentence of 7.1.6 here (with obvious changes) to describe what init-exprs are good for. Insert "An initialization expression is an expression with limitations that make it suitable for use as a kind type parameter or for an initilizer in a type statement." and then change first 3 words of next sentence to "it". 10) Page 116, 7.1.7 (2) and (10) seem somewhat redundant 11) Page 116, 7.1.7 (4). I'd like to interchange the text of (4) with that of Note 7.14. It's a shorter list, it's more likely to be correct as we add new intrinsics, and it's more obvious that what we disallowing the hard math functions so users can remember the pattern, not the list. 12) Page 117, note 7.15. ABS(9.0) is now allowed. change to ABS ( (9.0, -9.0) ) !not an integer or real argument. 13) Page 117, 7.1.8 last sentence of second paragraph. Shouldn't a function in a FORALL mask expression also be allowed to have side effects on the dependent statement? 14) Page 118, first sentence after note 7.16. Is this true for polymorphic things? Something like poly_1 .operator. poly_f(poly_2 .other_operator. poly_3) 15) Doesn't the evaluation of the argument to poly_f in general determine the type of poly_f and hence the type of the final expression? 16) Page 121, 7.1.8.5, sentence after note 7.27. Don't we need words here like in 7.1.8.3 about mathematical and computational equivalence? Something like X*Z .GT. X*Y becomes X*Y - X*Z .LT. 0 becomes X*(Y-Z) .LT. 0 and this might have different round off characteristics 17) Page 129, Note 7.37 continued. This isn't a continuation of the previous part of the note. It should be a separate note with an introductory sentence about how defined operators have separate precedences. Also the words about .starstar. duplicating the ** seem like the wrong words since it doesn't duplicate ** because it has a different precedence. 18) Page 129, 7.5.1.2 (2) If variable is not polymorphic can it have a dynamic type? 19) Page 129, 7.5.1.2 (2) Should the first line say dynamic and the last declared? Doesn't that mix things? 20) Page 129, 7.1.5.2. The last sentence defining derived type intrinsic assignment appears to be restating (1) and (2) above, but the words are somewhat different. For example is "accessible defined assignment" in (2) different from "no accessible generic interface ..." For example, (2) in 7.3.2 goes into detail about where an interface may come from and its typeboundness. Should that apply here? Or does "not polymorphic" cover it? 21) Page 130, 7.5.1.3. Do we need to distinguish details about where the interface is at ala (2) in 7.3.2? 22) Page 131, paragraph after note 7.43, the middle clause about nonpointer, nonallocatable. Does this mean that derived type assignment that is NOT type bound to the host type isn't used for the innards? Suppose I have a type PERSON with a component of type KIDS and with a subroutine that meets the requirements for KID_1 = KID_2. If I do PERSON_1 = PERSON_2 does the generic subroutine every get invoked? Does it depend on whether or not there is a type-bound assignment interface/routine in PERSON? Or in KIDS? I'm asking about an old fashioned generic assignment and how that fits in with the new type bound stuff. Same comment for the last couple of lines in (2) on the next page. It reads to me that we require "type bound procedures" when I thought generic assignment could work. 23) Page 132, 7.5.1.6 (2) Says there can be a type bound assignment procedure in EITHER X1 or X2. What happens if there is one in both and they are different? 24) Page 133, 7.5.2 R736 Does the second line allow something like A%B%pointer => P or only one %? Same question for R740 25) Page 134, 7.5.2.1 Second paragraph. Does this mean a monomorphic pointer can point to a polymorphic object if the types are OK? Or should dynamic type be declared type. 26) Page 134, 7.5.2.2, paragraph after unresolved issue. In the last two lines one of the proc-target terms should be proc-pointer-object. I think the second one. Right now it says proc-target may be elemental even if proc-target isn't. 27) Page 136, C728. I read this to say that an elsewhere in a named WHERE does not have to be named, but if it is, the name must be the same as the WHERE. It seems odd to require the endwhere to be named if the where is, but not the elsewhere. 28) Page 137, 7.5.3.2 (2). This means that the elsewhere mask expression is FULLY evaluated without being masked out. I think this is surprising and probably not what we intended. In something like WHERE (X == 0 ) ... ELSEWHERE ( 1/X > 10) ! evaluated for all of X ... ENDWHERE The same comment applies to a nested WHERE. This came up on (I think) the comp-f90 e-mail reflector and probably should be an F95 interpretation.