J3/05-245 To: J3 From: Malcolm Cohen Subject: Use procedureness in generic resolution Date: 2005/08/04 References: WG5/N1626, item UK-009. 1. Introduction This is work item UK-009 in WG5/N1626. It is on the B-list (5 yes, 12 like, 2 dislike). Estimated severity level is 3 (a small change to 16.2.3). Estimated small effect on implementations. 2. Basic Requirement Allow whether an argument is a procedure (its "procedureness") to be used to disambiguate generic procedure references. 3. Rationale One can always tell whether a name (or designator) is that of a procedure or of a data object. Users complain that since they can tell the difference, why can the compiler not? 4. Detailed Specification Consider a dummy procedure to be "distinguishable" from a dummy data object, for the purposes of generic resolution. 5. Further Technical Considerations In F2003, the requirement for type/kind/rank disambiguation from F90/95 was changed by the addition of "not a subroutine". I am unsure when this was added, but it was probably during one of the rewrites of that section which occurred during F2003 development. The rationale for adding "not a subroutine" as a clarification is that a subroutine has no type, and therefore cannot differ on type. As a practical matter, implicit typing means that one doesn't always know whether a procedure argument is a subroutine (has no type) or a function (has a type), so we must treat a subroutine as matching any type of function. However, the same argument does not apply to rank. An entity is only an array if it is declared to be an array - there are no "implicit dimensions". However, the words in F2003 prohibit a subroutine from disambiguating against an array function (or indeed an array object, but that is where we came in). There is no good reason for this, and it is arguably an incompatibility with Fortran 90/95. Regardless of the interpretation vis-a-vis incompatibility with F95, we should fix it in F2008. ADDITIONAL SPECIFICATION: That is, a subroutine should be considered to be "distinguishable" from an array function. Furthermore, "not a subroutine" does not successfully encapsulate the set of problematic (ambiguous) possibilities: in particular, when a specific procedure (in the generic set) does not explicitly type it and only passes it on to some other procedure, the dummy procedure is known only to be a procedure, not whether it is a function or subroutine. ADDITIONAL SPECIFICATION: We should fix the wording of "not a subroutine" so that it actually does what we want ("a procedure and not known to be a function" would be sufficient if excessively verbose). 6. Editorial Considerations The term "TKR compatible" is defined in 5.1.1.2 and used normatively only in 16.2.3 (it is also used informatively in Annex C). This term should be defined immediately before its use instead of 330 pages away. 7. Edits to 04-007 Move the paragraph (a single sentence) defining the term TKR compatible (the 6th paragraph of 5.1.1.2, [76:7-9]) to immediately precede the second paragraph of 16.2.3 (after Note 16.5, [407:28-]). In the process, change "entity" to "dummy argument" in the first instance, and delete all the other "entity"s, making the paragraph read: "A dummy argument is type, kind, and rank compatible, or <>, with another dummy argument if the first is type compatible with the second, the kind type parameters of the first have the same values as the corresponding kind type parameters of the second, and both have the same rank." Rewrite the paragraph (a single sentence) defining the term distinguishable (the second paragraph of 16.2.3, i.e. the one following Note 16.5, [407:28-29]) to be: "Two dummy arguments are <> if (1) one is a procedure and the other is a data object, (2) they are both data objects or known to be functions, and neither is TKR compatible with the other, or (3) one is a function with nonzero rank and the other is not known to be a function." ===END===