J3/02-122 Date: February 8, 2002 To: J3 From: Dick Hendrickson Subject: Update to 01-375 Chapter 4 comments This is an update of 375 from meeting 159, which was an update of 280/R2 from meeting 158. Page, etc., numbers have been updated to the current 02-007 PDF version. Items which were answered by 01/401 or withdrawn are deleted here 5) Page 33[8-10], 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. They "assume" a size <= the actual size. 8) Page 35[20] new constraint C408 about where BOZ can appear. Is it clear what "first argument" means? Something like REAL(KIND=B"0100", A= 25) is wrong. This might be covered by the way key-word args are defined. This is a complete restatement of the previous comment. 11) Page 41, C414. Should we say what happens if it is the same as a intrinsic processor defined type not defined in the standard. A processor can extend the standard by adding new types. How chould the user protect himself? And what happens if he doesn't use protection? 13) Page 43, C429 and C430. Are we being too clever with the words "previously defined" and "accessible"? Normally I think of "accessible" as meaning defined (before) here 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. Last time sub-group proposed no action saying "accessible" does not mean "defined before". But I don't think this is an answer. Why do we not allow nonpointer use of forward accessible things in 429 yet allow forward references to accessible types in 430? 17) Page 44, 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 44, 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. 21) Page 46[8-9], 4.5.1.1, 5th paragraph, just before note 4.21. What is "the exception stated below"? I didn't see one. Also, 45[1-2] uses "described below". This is too many vague forward references. 22) Page 46, 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[10-14], 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 46, 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 47, 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[2-11], 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 48, 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. Or maybe change the words to "will be used for" 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 49, 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 50, 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 53, 4.5.1.9, note 4.43 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 50[13-14], 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 51[16-17], last sentence before note 4.45. Does this sentence add anything? I think it just restates the previous two. 37) Page 55, notes 4.48 and 4.50. These look awfully normative to me. Are they deducible from constraints, etc? 38) Page 55, note 4.51. I think an example showing a reference to POINT, COLOR and X would help. 39) Page 55 and 56, notes 4.51 and 4.52. I'm confused here about what he 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) I think an example or aditional note would help. 40) Page 56[11], last sentence in 4.5.3. Can it be extended generically? 43) Page 58, C476 I don't understand this constraint, could it be said clearer? If I do sort of understand it, should it also be a onstraint 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 58, 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 58[12-13], 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 58[14], 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 59, 4.5.10 Finalization process. 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 59[16-23], 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 finalized separately, is it in array element order or processor dependent? 49) Page 59[22-23], 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[29], 4.5.10.1 when finalization occurs. 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 last 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 61, note 4.61. Please add an example of a type with parameters 52) Page 62, note 4.62. Should the last sentence be "NOT interoperatable"? In either case, shouldn't this be normative text? 53) Page 63, 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. 55) Page 64, examples. Need one with a type spec. Maybe the simple one with dim from earlier will work. Also, something like [character(10):: 'tom', "dick", "harry"] would show a practical use.