J3/01-385R1 Date: November 29, 2001 To: J3 From: Dick Hendrickson Subject: Technical issues in Chapter 8 1) Page 152[15] C808. Why do we need this constraint? None of the other syntax for SELECT TYPE depends on having an associating name. Granted, it's useful thing in many cases; but why should it be required? PROPOSAL Change C808 to "NOTE nnn Usually if the selector is not a simple name an associate-name will be used. Otherwise there is no easy way to refer to the selector within one of the type-guard-statement blocks." If we do this we need to check the wording to effectively add "if any" in a few of the descriptions of the associate-name. 2) Page 152[17] C810. Do we need this constraint? It seems to me it prevents stubbing out SELECT TYPE constructs during code development. We allow things like INTEGER, PARAMETER :: I = 7 SELECT CASE (I) ... Isn't a SELECT TYPE with a non-poly-morphic selector the same sort of thing? No action, reason for select type is to deal with polymorphic things. 3) Page 153[9,10] section 16.7.1.5 describes association between two things and says the association is broken at the end of the block. But here lines 9 and 10 say that in the degenerate case the name itself is the associate name. It sounds odd to me to say that a thing gets associated with itself and later on disassociated from itself. I think we need to clarify 16.7.1.5 for the degenerate case. No action needed 4) 154[20] Selectors don't have a "declared type" if they are expressions (or maybe even if they are implicitly typed). Same problem with C811, page 153, and other uses of "declared type of the selector" No action needed. Section 5.1.1.8 talks about the declared type of a data entity. Section 2.4.3 says a data entity is the result of an expression (among other things). Therefore, it makes sense to talk about the "declared type of an expression". 5) 154, C815. C815 would appear to allow assigning to an associated name that is associated with a protected variable. That coupled with 8.1.4.5 seems to imply that the associated name is not protected. Proposal: Change note 8.13 to normative text (as modified by 384R1) 6) Page 154[27]. Should other attributes also leak in? How about OPTIONAL, PARAMETER, PROTECTED, and VALUE? No action needed note 8.13 is made normative except for OPTIONAL. 7) Page 154, 8.1.4.5 I'd read 16.7.1.5 as to say that a line like ASSOCIATE ( name => george) doesn't reference george. So, is george allowed to be OPTIONAL? Proposal: Page 154, line 28 Add "If the selector has the OPTIONAL attribute, it must be present." 8) Page 154[27]. What does "same rank and bounds" mean? Does it mean as if LBOUND and UBOUND were applied to selector? Other places (e.g. 137[7] ) explicitly talk about LBOUND and extent. Yet natural English implies that ASSOCIATE (A => array(3:7) ) will give A with bounds 3 and 7. This seems to also be the natural shorthand intent of ASSOCIATE. I think the intent is that the association be dummy argument like with bounds 1:extent, but we should say that. We could also do something like we did for POINTER and allow associate-name[(bounds-list)] => selector with suitable constraints on bounds-list to preserve the "natural" subscripts. Or perhaps associate-name[(:,:,:,:)] => selector to mean that the associate gets the actual bounds, not 1:extent. I'm not sure what the committee's intent was here. /A believes that the intent is to treat the bounds as if LBOUND and UBOUND were applied to the selector. The edits are modeled on pointer assignment, 137[7]. Proposal: Page 154, lines 26-28, replace with Within a SELECT TYPE or ASSOCIATE construct, each associating entity has the same rank as its associated selector. The lower bound of each dimension is the result of the intrinsic function LBOUND (13.7.58) applied to the corresponding dimension of . The upper bound of each dimension is one less than the sum of the lower bound and the extent. It has the ASYNCHRONOUS, INTENT, TARGET, or VOLATILE attribute if and only if the selector has the attribute. 9) Page 382, lines 5 to 13. I think there is a problem with limiting the scope of the associate name to the BLOCK of the construct. This leave out the header line. I think there was a similar interp about FORALL (I = I, I+1), but I don't remember the details. Given something like name = 0 associate (name => name + 1) print *, name end associate It's clear that the use of name in the print refers to the associate name. But, what about in the associate line itself? And what about associate (name => name+1, other_name => name+2) No action needed, we believe that names top the right of the => are global, names to the left are local to the construct. Both of the above examples are just fine.