To: J3 J3/22-143 From: Malcolm Cohen Subject: Improved wording and technical fixes for conditional args Date: 2022-March-07 1. Introduction Some of the wording of conditional arguments is a bit sloppy, and it could be better described. There is also a long-standing contradiction in the standard that conditional arguments give a greater prominence to; we should fix that. Sections 2 and 3 are merely background. Section 4 describes an alternative approach, but although it is philosophically different, the existing approach seems just as workable. Section 5 contains the actual edits that are being proposed. Section 6 has some "rejected" edits, explaining why they are not needed. Section 7 has some "optional" edits. These really are just attempts at wording improvements, so we do not need to rush into them. 2. General approach - discussion We will start by looking at how our existing terminology works. The BNF actual-arg is always the thing in the argument list. Our tendency to use prose instead of BNF means that we have defined "actual argument" to mean the same thing. * This is already wrong and has been wrong for twenty years now! * Let me re-emphasize this: the definition of "actual argument" is wrong, and has been wrong longer than we have had formally defined terms in normative text! It was wrong in Fortran 2003, when the Glossary was in Annex A, and that was "informative" not "normative". That is because a) in the case of defined assignment, the actual argument is or "the enclosed in parentheses (since Fortran 90); b) in the case of an operator, it is some kind of operand (since Fortran 90); c) in the case of a passed-object dummy argument, the actual argument is part of the procedure-designator. So here is how our existing terminology actually works (to the extent that it is not already broken, anyway): - the BNF actual-arg is always something that appears in an argument list in a procedure reference; - the "actual argument" is the thing that corresponds to a dummy argument in 15.5.2.4 Argument association - here, in the case of a conditional-arg, it is the consequent-arg that is the actual argument not the conditional-arg; - the "effective argument" is always the thing that is argument- associated with a dummy argument. Only in "traditional Fortran" (i.e. FORTRAN 66 or 77) is the term "actual argument" not used inconsistently. Once Fortran 90 introduced depointers, from that point on, it was used ambiguously. In Fortran 2008 days, /DATA subgroup disentangled "effective argument" from "actual argument", which was a big step forwards. But even after that, many poor uses of "actual argument" to mean "effective argument" remained; some of these did not introduce much ambiguity or contradiction because they were in a context where pointers were not in play. 3. How to fix this Well, we can start by fixing the definition of actual argument so that it does not say anything wrong. Probably the only way to do this is so that it does not say anything much at all! We also need to fix any problems with conditional arguments. The problems that may exist for other contexts, like defined operators, can be swept under the carpet for now, on the grounds that "we all know what we mean", even though we've not managed to articulate it clearly. In the long run, of course all the problems should be fixed, but in the short term, we only need to make sure we don't make things too much worse. 4. An alternative approach For conditional arguments, a different approach would be to say that the actual argument should be the actual-arg BNF, and that the "effect is as if the consequent-arg were the actual argument". We already have rules in 15.5.2.3 Conditional argument corresponence which should make that work. This is not actually very different from what we do now, and although it might fix some problems, I think all the worst ones still need correction. Here is the basic edit for that. [320:10-12] 15.5.2.3 Conditional argument correspondence, p2 Change "its expr or variable is the actual argument" -> to "the effect is as if its expr or variable were the actual argument", Change ", and if" to "; if", {This doesn't do very much by itself, but might be philosophically nicer?} 5. Actual edits to 22-007 [3:8] 3.1 actual argument, replace existing definition with "entity that determines argument association (15.5.2.3, 15.5.2.4) NOTE 1 An , , or in a defined assignment statement, are all examples of actual arguments." {That is a reference to Conditional argument correspondence, and a reference to Argument association. It's not very informative, but it's a lot better than trying to list all of the possibilities, e.g. "actual-arg, consequent-arg, expression, variable, operand, or base object in a procedure-designator" ...and even that list is incomplete as I've forgotten defined i/o!} [320:12] 15.5.2.3 Conditional argument correspondence, p2 Change "there is no actual argument for that dummy argument" to "the actual argument for that dummy argument is not present". {As there is an actual-arg, one might reasonably expect there to be an actual argument; this rewording avoids that confusion whilst maintaining the semantics.} [320:18] Same subclause, same paragraph, append "It is simply contiguous if and only if all of its consequent-args are simply contiguous." {We want this for the simply contiguous conditions to be compile-time ones. Really, it follows from p3 anyway, but it would not hurt to have it be more explicit.} 6. Some edits not done There is nothing giving the conditional-arg the TARGET attribute because the rules for TARGET already apply to the effective argument, so there is no possibility of confusion. We could have added "It is a coindexed object if and only if any of its consequent-args is a coindexed object." to get the rules for coindexed objects as actual arguments applied to conditional arguments, but we do not need to do this because we already have the requirement in p3 that "Each consequent-arg in a conditional-arg shall satisfy any requirements of the dummy argument on declared type, kind type parameters, attributes, and properties that do not depend on evaluation of the consequent-arg or any contained expressions." This requirement applies all those rules to the consequent arguments, so we do not need to rewrite things. 7. Optional edits There are quite a lot of places where "actual argument" is used when "effective argument" might be better; this goes back to the original state where the standard was hopelessly confused and used "actual argument" to mean both the "thing in the argument list" and the "thing the dummy argument is associated with". When /DATA was disentangling this for Fortran 2008, the approach was to leave the wording alone except when it was unambiguously wrong. That was a good approach at the time, at least for reducing the amount of work needed, but has left some suboptimal wording in various places. And unfortunately, modification by copy-pasting has promulgated "actual argument" into other places where we didn't really need to. Below are some edits where "effective argument" would probably be better. They do not appear to be actually "wrong" though. [322:8-10] 15.5.2.5 Ordinary dummy variables, p4, Change first two "actual argument" -> "effective argument". {i.e. everything except the last "actual argument element sequence". That too should probably be "effective argument element sequence", but the sequence association subclause is ugly and already being fixed, so let's leave this alone for now.} [322:15] p6, "actual argument" -> "effective argument". {Not really needed because 15.5.2.3p3 already applies this requirement onto any consequent-arg variable.} [322:21] p8, "used as an actual argument that corresponds" -> "passed", i.e. we end up with "If such a dummy argument is passed to a dummy argument with the TARGET attribute..." {Either we should do this, or change it to "If such a dummy argument is an effective argument associated with a dummy argument with the TARGET attribute... ===END===