J3/97-204 Date: 1 Aug 1997 To: J3 From: R. Maine Subject: Edits for M.2, Intent for Pointer Arguments This paper proposes edits for M.2, Intent for Pointer Arguments. The specs and syntax were approved in paper X3J3/96-098R1. The edits below are all against J3/97-007. This paper presumes prior passage of the edits in 93-202 to clean up the definitions of subobject and related material. A few of the edits may well overlap edits later needed for procedure variables/pointers, because both dummy pointers and dummy procedures were formerly disallowed from having INTENT, and both restrictions might be lifted (not yet finalized for dummy procedures). Explanations tagged as "Note to J3:" explain the edits, but are not actually part of them. In 5.1 [48:7] 6th constraint after R506. Delete ", INTENT". In 5.1.2.3 [53:11] First constraint after R512. Delete " or a dummy pointer". [53:13] After "A" add " nonpointer" [53:14] "as" -> "in a variable definition context (14.7.6). Note to J3: The edits to fix and move the list from [53:15-26] are detailed separately later in this paper. [53:26+] Add a new constraint "Constraint: A pointer dummy argument with the INTENT(IN) attribute shall not appear as (1) A in a or , (2) An in an or , or (3) An actual argument in a reference to a procedure when the associated dummy argument is a pointer with the INTENT(OUT) or INTENT(INOUT) attribute." [53:27] After "attribute" add " for a nonpointer dummy argument", and change "the dummy argument" -> "it". [53:28] Add a new sentence as part of the same paragraph. "The INTENT(IN) attribute for a pointer dummy argument specifies that its association shall not be changed during the execution of the procedure." [53:29] After "attribute" add " for a nonpointer dummy argument", and change "the dummy argument" -> "it". [53:33] Add as new sentences as part of the same paragraph. "The INTENT(OUT) attribute for a pointer dummy argument specifies that on invocation of the procedure the dummy argument becomes disassociated. Any actual argument associated with such a pointer dummy shall be a pointer variable." [53:34] After attribute add " for a nonpointer dummy argument", and change "the dummy argument" -> "it". [53:35] Add a new sentence after "unit. " "Such a dummy argument may be referenced or defined. " Note to J3: Just to be explicit, since I'm deleting such words from 12.5.2.1. [53:36] Add as new sentences as part of the same paragraph. "The INTENT(INOUT) attribute for a pointer dummy argument specifies that the dummy argument is intended for use both to recieve a pointer association from and to return a pointer association to the invoking scoping unit. Any actual argument associated with such a pointer dummy shall be a pointer variable." [53:44++] Add a new paragraph at the end and as part of the shaded note added here by paper 97-202. "Similarly, the INTENT restrictions on pointer dummy arguments apply only to the association of the dummy argument; they do not restrict the operations allowed on its target." In 5.2.1 [58:5] First constraint after R520. Delete " or a dummy pointer". In 5.2.7 [60:16] First constraint after R528. Delete the constraint. In 12.3.2.1.1 [196:31+] Add a new shaded note BEGIN NOTE In Fortran 90 and Fortran 95, it was not possible to define operators on pointers because pointer dummy arguments were disallowed from having an INTENT attribute. The restriction against INTENT for pointer dummy arguments is now lifted, so defined operators on pointers are now possible. However, the pointer attribute can not disambiguate generic procedures (14.1.2.3), so it is not possible to define a generic operator that has one procedure for pointers and another procedure for nonpointers. END NOTE In 12.4.1.1 Note to J3: Boy, I hate this section. It makes my brain turn to mush, particularly all the target stuff. I'm really surprised that the section formerly managed to avoid even mentioning INTENT until the last 2 short paragraphs. I'm suspicious that some of the earlier material might not be strictly correct for all INTENTS (and purposes?...sorry, couldn't resist). But since I have trouble reading this section at all, I can't really tell. I'll concentrate on making sure that the pointer dummy case is ok, because that's the one I'm changing. I give no guarantees about the rest. Luckily, pointers can't be targets, so I don't have to dig into the bad stuff; the pointer dummy part looks pretty clear and explicit (in fact, more so than the really trivial cases, like scalars without any "strange" attributes; I don't off-hand see where this explains those nearly as clearly as it explains pointers. I'm sure the semantics of the simple case must be explained somewhere, but I'm not going to get further sidetracked by chasing that line of thought). [200:23-26] Replace the first three sentences of this para with "At the invocation of the procedure, a dummy argument pointer becomes disassociated if it has INTENT(OUT). If it does not have INTENT(OUT) then it receives the pointer association status of the actual argument and, if the actual argument is currently associated, the dummy argument becomes associated with the same target. The association status of a dummy pointer argument may change during execution of the procedure unless it has INTENT(IN). [200:29] After "argument" add " unless the dummy argument has INTENT(IN)". [201:19] before "dummy" add "nonpointer " [201:24-45] Move note 12.17 to [53:44+], at the end of section section 5.1.2.3. This should follow the material added there by paper 97-202. Note to J3: Perhaps debatable, but I think this note goes better with the definition of the INTENT attribute. None of the other edits herein depend on this move, however. In 12.4.1.6 [205:2] Note 12.23. Before "dummy" add "nonpointer ". In 12.5.2.1 [205:29-32] Copy the sentence from these lines to [53:38] as a new sentence appended to that para. [205:22-31] Delete the section (after doing the copy above). Note to J3: This whole section is redundant. It said essentially nothing that wasn't already said in 5.1.2.3 in more detail. My edits (one right above and one earlier) make sure that the only 2 things here that elaborated in any way over the 5.1.2.3 material are now copied into 5.1.2.3, leaving this section pretty pointless. I've just removed the whole section. If people prefer, a plausible alternative is to leave the section, but cut it to 2 sentences - the first one as in f95, and the second one just saying something like "See 5.1.2.3 for details." Or the same 2 sentences could just be a para in 12.5.2 without giving them a separate section header. In 13.3 [218:2] Delete "nonpointer". In 14.6.2.1.2 [285:9+] Add new item "(5) A procedure with the pointer as an INTENT(OUT) dummy argument is invoked." Note to J3: Looks to me like 14.6.2.1.* fail to cover the interactions between pointer dummy and actual arguments. If that was covered, then presumably it would need to be edited to reflect the cases with specified INTENT. In Annex A [297:12] INTENT glossary entry "that is neither a nor a , which" -> " that" Note to J3: The original failed to consider alternate returns. In C.9.5 [336:41] "POINTER" -> "POINTER, INTENT(OUT)" [336:42] "TARGET" -> "TARGET, INTENT(IN)" Note to J3: These edits just add INTENT to a pointer arg example. The following edits address the numbered lists of contexts where variables are potentially defined, redefined, or undefined. In f95, these lists appear in sections 5.1.2.3 and 12.6 as places where some variables are not allowed to appear. The current lists have several problems. First, the lists are just presented without description of their derivation. It requires "reverse engineering" to deduce the concept behind the lists. This presentation makes them seem arbitrary and also makes it difficult to deduce when new language features should affect the lists. Second, the two lists are largely duplicative, making it quite an exercise to determine what the differences between them are and why. The common items in the lists aren't even in the same order. As Dick Weaver would probably have reminded us, this probably means that (at least) one of the two list is probably wrong. Looks like he would have been right - see my edits for items 9 and 10. Hmm...in fact digging through my stack of papers that I was meaning to follow up on "some day", I see that Dick did, in fact propose consolidating the discussions of INTENT back in 1994. Third, I think some of the detailed wording is confusing, being too specific when generality seems better (mostly in section 12.6), yet too general where specificity would clarify (about implied DOs). So the following edits do several things. We combine the common elements of the lists into one. This common portion turns out to look a lot like the list currently in 5.1.2.3, with two small additions and one clarification. Items 7 and 8 from the list in section 12.6 are not part of the merged list. They really do apply only to PURE procedures, so we will keep them in section 12.6 as separate constraints. We add a few sentences of description for the list to explain how it is derived. In its combined form, I think the list goes best in section 14.7, rather that directly in either 5.1.2.3 or 12.6. It is not so much about the INTENT attribute (section 5.1.2.3) or PURE procedures (12.6) as it is about definition of variables (14.7). Both of the two earlier sections just reference the list. In fact, the list ties quite closely to the lists already in section 14.7; the main distinction is that sections 14.7.5 and 14.7.6 list events, whereas the new subsection lists syntactic contexts. If there is objection to putting it in section 14, my second choice is 5.1.2.3. [53:16] (item 2) "The" -> "A", "of" -> "in", and add "or " before the comma. [53:17] (item 3) "implied-DO" -> "io-implied-DO" Note to J3: This has the same technical result, but the specific form seems more clear. The other forms of implied-DO (data and ac) are not relevant because the variable in those forms has scope of only the implied DO and thus never affects the definition status of a variable of the same name in the local scope. But this takes a "guru" to deduce. By specifically saying io-implied-DO in the first place, it seems significantly more clear to me. [53:26] (item 10) "or INTENT(INOUT)" -> ", INTENT(INOUT), or POINTER" Note to J3: The edits to item 2 and 10 are needed to cover parts of the list in section 12.6 that weren't in 5.1.2.3; their omission from 5.1.2.3 appears to have been an error. (Yes, even in f95 without INTENT for pointer arguments, because there can be pointer subobjects of INTENT(IN) arguments in f95). [212:37-42] replace items (1)-(6) with the single item (and, of course, renumber the rest). "(1) In a variable definition context (14.7.6);" [212:43] After the ";" add " or" [212:45] ";" -> "." [213:4-7] Delete items 9 and 10. [291:29+] Add new section "14.7.6 Variable definition context Some variables are prohibited from appearing in a syntactic context that would imply definition or undefinition of the variable (5.1.2.3, 12.6). The following are the contexts in which the appearance of a variable name implies definition or undefinition of the variable:" Move the list [53:15-26] from section 5.1.2.3 to here (after doing the edits to it listed above). Annex B [305:29-30] "constraint...5.1.2.3" -> "to the list in 14.7.6" Question: Should we require that the intent of pointer dummy arguments of pure procedures be specified? (Constraint after R1205, plus the first 2 constraints in section 12.6)). If that part of the constraints remains, it is going to seem inexplicable. If it is removed, we will introduce an incompatability, which will then need to be mentioned in section 1. Note that it would be an incompatability only with f95, not with f77 or f90 (because they didn't have pure procedures at all). The edits of this paper maintain f95 compatibility, but I'm not at all sure whether or not that is the aproach that J3 will prefer.