J3/01-283R1 Date: August 23, 2001 To: J3 From: Dick Hendrickson Subject: Chapter 7 comments >> Subgroup recommended actions 1) Page 107, Note 7.1, 7.2, and 7.3. These don't add anything to the text and should be deleted. >> Page 107, delete note 7.1, 7.2, and 7.3 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. >> Page 113:9 After "function reference," add " type parameter inquiry, and type parameter name," 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. >> nothing needed 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. >> nothing needed 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 >> nothing needed 6) Page 114, 7.1.6. (5) and (11) seem somewhat redundant >> nothing needed 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". >> nothing needed 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. >> nothing needed 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. >> 117:11+ Insert "An initialization expression is an expression with limitations that make it suitable for use as a kind type parameter or for an initializer in a type statement." 10) Page 116, 7.1.7 (2) and (10) seem somewhat redundant >> nothing needed 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. >> nothing needed 12) Page 117, note 7.15. ABS(9.0) is now allowed. >> 117:23 change to "ABS (9.0)" to "ABS( (9.0, -9.0) ) !not an integer or real argument." 13) Page 117, 7.1.8 last sentence of third paragraph. Shouldn't a function in a FORALL mask expression also be allowed to have side effects on the dependent statement? >> 117:36 Change "subscripts and strides" to "subscripts, strides, and mask expression" 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) >> defer 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? >> defer 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 >> 121:27-28 Change "their logical...primary" to "they are mathematically equivalent" 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. >> 129:1 make into a new note, not a continuation. 129:2 delete "For example, " and capitalize 18) Page 129, 7.5.1.2 (2) If variable is not polymorphic can it have a dynamic type? >> nothing needed 19) Page 129, 7.5.1.2 (2) Should the first line say dynamic and the last declared? Doesn't that mix things? >> defer 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? >> defer 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? >> defer 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. >> defer 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? >> defer 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 >> defer 25) Page 134, 7.5.2.1 Second paragraph. Does this mean a non-polymorphic pointer can point to a polymorphic object if the types are OK? Or should dynamic type be declared type. >> defer 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. >> defer 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. >> defer 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. >> defer