J3/01-375 Date: November 15, 2001 To: J3 From: Dick Hendrickson Subject: Chapter 4 comments, updated from meeting 158 This is an update of 280/R2 from meeting 158. Page, etc., numbers have been updated to the current 007/R4 PDF version 1) Page 31[9], First line after note 4.1. The forward reference in "definition is accessible(4.5.1)" seems odd. It looks associated with "accessible", but 4.5.1 is the definition syntax. PROPOSAL Delete (4.5.10 on 31[9] 2) Page 31[17], 4.1.1, third line. Add "character" to integer and real and commatize the list. There's only 6 types; it seems odd to omit only one of them from the general blather. 3) Withdrawn 4) Withdrawn 5) Page 33[7-9], paragraph after note 4.5. I'm confused about the difference between deferred ":" and assumed "*" nonkind type parameters. The paragraph before 4.5 says deferred get a value from argument association. This one says assumed assume the arguments value. What's the difference? Also, does this imply something about assumed size dummy arguments? They don't really assume the size of the actual arguments. the "assume" a size <= the actual size. 6) Page 31[9-10], 4.1.3, second paragraph, first sentence. This is said much better in the third line in the paragraph before note 4.6 (page 33[19-26]). The question is "agreement" between what. Also, shape is important. I think this was said somewhere else and it bothered me there also. I'd almost withdraw this, the rewording for 007/R4 is better But, page 16[13] has the old wording that says "intrinsic operation with agreement..." and also needs to be redone. Probably should take 16[13], 31[9-10] and 33[19-26] and only say it once. 7) page 34, R402 etc. Rules would look better if 402 was moved to after 407 and 403 was moved to after 405. The main thing being defined here is signed-int-literal-constant 8) Page 35 [20-21], paragraph before 4.4.2. This sometimes causes problems, especially now that we allow BOZ anywhere. Why not add an optional _kind to BOZ? Limit kind values to the same as for integers. 9) Page 36, note 4.11 Change "0.45E-4" to "0.45D-4" completeness should include double precision 10) Page 40[33-34], section 4.5 4th paragraph. This cries out for an example!!! Given something like type :: kids type (person) :: oldest_child type (person), allocatable :: other_kids(:) end type kids type (kids) :: my It seems counterintuitive to me that, e.g.., my%oldest_child%age is an ultimate component, but my%other_kids(1)%age isn't. It's really not clear here what the utility of "ultimate component" is. 11) Page 41, C413. Should we say what happens if it is the same as a intrinsic processor defined type not defined in the standard?? 12) Page 41, C417 and C418. These don't appear to be constraints against the named Rules. Neither of them allow SEQUENCE as an option. Should SEQUENCE also be an option in R425? 13) Page 42, C428 and C429. Are we being too clever with the words "previously defined" and "accessible"? Normally I think of "accessible" as meaning defined (before) here and/or brought in from a module or host association. In C429 we seem to mean defined before or after here to allow for recursive types. Maybe a NOTE would help here describing why you can have a pair of recursive types that point to each other, but not that contain each other. 14) Withdrawn 15) Page 42, C435. I don't see how this applies to the named rule. Where would the type-param-value be? 16) Page 42. C435 C501 seems similar to C435, but doesn't contain the restrictions about constants, etc. Why? 17) Page 43, R438 and R439, Wouldn't this be clear if we put [PRIVATE] as the second line of the rule and dropped R439 and changed C442 accordingly? The only use of binding-private I could find were in these 3 lines. 18) Page 43, R438. Why do we only allow PRIVATE, I think everywhere else we allow both PUBLIC or PRIVATE. Especially a problem since we allow mixed modes and the PUBLIC or PRIVATE from above doesn't propagate down. Even if redundant, it's good for documentation. 19) Page 44, C460. It's unclear at first reading how the "an accessible" propagates past the "or". I think all external procedures are accessible, so I'd change "or" to "or an" to clarify it. 20) withdrawn 21) Page 45[15], 4.5.1.1, 5th paragraph. What is "the exception stated below"? I didn't see one. Also, [9] uses "described below". This is too many vague forward references. 22) Page 45, note 4.21, first example. I'd add at the end of the text "D does not have the KIND attribute", or "D has the nonkind attribute. I'd also like to see an example where a thing is used both as a kind and nonkind parameter for completeness. 23) Page 45[1-4], 4.5.1.1, paragraph before note 4.22. This is a hard to parse sentence and a strange requirement. Wouldn't it be better to REQUIRE KIND or NONKIND for everything and not try to make them be implicit? Or say every parameter is implicit INTEGER,KIND unless it's explicitly type by the user? The idea of magic context sensitive defaults seems hard to describe. 24) Page 45, 4.5.1.1, note 4.22. I'm not clear about what happens if one type has a non-kind type parameter. Something like type t1(a) integer, kind :: a type (t2(a)), pointer :: comp end type t1 type t2(a) real array(a) end t2 Is this OK? Is the "integer, kind::a" required if there is a "real(a) :: scalar" statement in the definition of t1? Does it matter if it comes before or after the line for comp? 25) Page 46, 4.5.1.2 Notes 4.23 and 4.24 should be combined into one note since the second refers to the first. 26) Page 46, 4.5.1.2. First paragraph and allocatable components. As I understand it, you can't specify default initialization for an allocatable component array. Is that right? If so, it should be mentioned here since this is where people will look for info on default initialization. The prohibition on default initialization of allocatable components seems odd. I can have an allocatable array of a derived type that has default initialization for it's components. Why shouldn't we be able to initialize the allocatable components? At least to a scalar? 27) Page 47, note 4.26. I spent a lot of time trying to figure out how coord(:1) got initialized to contain (/ X1, Y1/). Remove the comments following the !'s in the type and change "COORD" to "END_POINTS". Let the reader guess which dimension is x/y and which is the point number--it doesn't matter. But comments that imply something has a value are confusing If not, then line up the !'s for neatness 28) Page 48, Note 4.27. Why isn't the shape also determined for array variables of type STACK? How does argument association determine the size? Isn't that an odd way to say it? Is this a new part of OOP? I think it's an odd thing to say since an argument might be unallocated and hence not have a shape. 29) Page 48, Note 4.28 C436 says we can't initialize allocatable components. If that's what we intend, it needs to be said here, especially since the previous example had an allocatable component array. 30) Page 48, note 4.29. It's odd to say 4 components plus a pointer. That, to me, implies that the pointer isn't a component. Better to say "5 components, one of which is a pointer..." Also, the sentence "the size of the target array will be determined by the size of the abstract" should be deleted. It's wrong and it implies some form of magic that doesn't happen. The last sentence says how the size gets determined. If I do my_thesis%abstract = "a lot of really interesting stuff about rocket science..." that doesn't determine the size of the array! Also, the def of ABSTRACT is unusual. I wouldn't expect to use a character array to hold a text thing like an abstract because there's no easy way to initialize it. 31) Page 49, note 4.31 The phrase "same module" has no antecedent. At least add something like "declared in a module" to the first line, or better add a module name and a contains. 32) Page 49, note 4.32 This sounds like normative text to me. I couldn't deduce the last sentence from reading 16.1.2.4.4. Does it mean that an ERR= branch must be taken? 33) Page 51, note 4.38. The following notes should include examples of all 4 combinations along with some text describing how they would be used. 34) Page 51, 4.5.1.9 SEQUENCE. We should put a sentence at the end of the long note something like "A SEQUENCE statement forces the processor to assign storage to elements in the same order as they are declared. This might cause inefficiencies, such as data misalignment, but may be useful for interchanging data with non Fortran processors." 35) Page 49[15], 4.5.1.7. I don't understand the term "might". I couldn't see anything in 4.5.10 that made it look like it was optional. Isn't true that if there is a finalizer, it is executed when the variable goes away? 36) Page 50[10-13], last sentence before note 4.45. Does this sentence add anything? I think it just restates the previous two. 37) Page 54, notes 4.48 and 4.50. These look awfully normative to me. Are they deducible from constraints, etc? 38) Page 54, note 4.51. I think an example showing a reference to POINT, COLOR and X would help. 39) Page 54 and 55, notes 4.51 and 4.52. I'm confused here about what the components are named in an extended type. If I do TYPE (COLOR_POINT) :: pixel then can I do PIXEL%X= 3 or must I do PIXEL%POINT%X = 3? Can I do PIXEL%POINT = POINT(3,4) 40) Page 55[16], last sentence in 4.5.3. Can it be extended generically? 41) withdrawn 42) withdrawn 43) Page 56, C475 I don't understand this constraint, could it be said clearer? If I do sort of understand it, should it also be a constraint against type or variable definitions? If I have a type that has components X1 and X2 then shouldn't the rule be that the type can't be named MAX? That's where the ambiguity comes from that (I think) note 4.53 defines away. Constraints are usually prohibitions about what sort of syntax you can write. But if I understand the note, I CAN happily write MAX(X1=1,X2=2), it's just not a constructor. Anyhow I'm confused here (see the next comment if you don't believe me). 44) Page 57, note 4.53 I don't understand this either. What about the form "name(...)(...)" where "name(...)" is a generic looking thing. Is that what C475 is trying to prevent? Also, note 4.53 sounds normative to me. If I have a type MAX with components I and J where does it say that MAX(3,4) is the intrinsic function and MAX(I=3,J=4) is the structure constructor? 45) Page 57[14-15], sentence before note 4.54. I don't understand this sentence. The last line in the example in 4.54 does specify parent components even though the lead in text says no parent components appear in component order. 46) Page 57[16], sentence between notes 4.54 and 4.55. Does this mean we can't initialize mutually recursive derived types? Or maybe even recursive ones? 47) Page 58, 4.5.10 I don't understand the finalization process. It looks like the first thing that happens is that a FINAL routine is called with the entity as the argument. Then final routines are called on a component by component basis. I would think that a FINAL routine would clean up the whole thing. In effect, the final routine for the entity deletes the entity, or returns all of it's storage, etc. But this can't happen this way here. I think this needs clarification, probably a NOTE. Suppose I have a type (PARENT)that has finalizers and also has an allocatable component of a type (CHILD) that also has a finalizer. Suppose I do a DEALLOCATE (PARENT_THING). In the finalizer for the PARENT type should I, must I, or shouldn't I deallocate CHILD? 48) Page 58[25-26], 4.5.10 (2). This seems to contradict (1). Are the components finalized first? Also, if the thing is an array, why are the elements finalized separately, why not allow for elemental as in (1). If they are finalizzed separately, is it in array element order or processor dependent? 49) Page 58[25-26], 4.5.10 (2). Does this imply recursive finalization if a component is a pointer to a thing of the same type? What about mutual recursion? Is it allowed for me to do deallocate (head_of_house, wife, kids) where the appropriate types all contain pointers to the other variables. 50) Page 59[12-15], finalization. The requirements are unclear to me. In 10 continue ... DO i = 1,100 w(i) = finalizable_function(...) x(i) = finalizable_function(...) if (...) go to 10 y(i) = finalizable_struct_constructor(...) if (...) z(i) = finalizable_struct_constructor(...) enddo the things are only finalized once at loop exit, not in between references? Does the processor have to trap the GOTO and do the finalization just before it jumps out of the loop? For the if controlled assignment the processor will have to remember if the assignment actually took place? Also, the word "construct" distinguishes between an IF statement as above and an IF-ENDIF block. So presumable if the if were replaced with if(...) then z(i) = finalizable_struct_constructor(...) endif that constructor would be frequently finalized. What happens for a FORALL statement where we say roughly "A forall statement is the same as a forall construct with the action statement as the only statement in the block.? Is this text intended to allow optimization in loops? 51) Page 60, note 4.61. Add an example of a type with parameters 52) Page 61, note 4.62. Should the last sentence be "NOT interoperatable"? In either case, shouldn't this be normative text? 53) Page 62, R459. What is the use of the first form? Is something missing? There should at least be an example in one of the following notes showing [integer::] as a zero sized array. 54) withdrawn 55) Page 63, examples. Need one with a type spec. maybe the simple one with dim from earlier will work. Also, unless Richard objects, something like [character(10):: 'tom', "dick", "harry"] would show a practical use.