To: J3 J3/22-143r1 From: Malcolm Cohen Subject: Improved wording and technical fixes for conditional args Date: 2022-March-09 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 in the r0 describes an alternative approach, but although it is philosophically different, the existing approach seems just as workable, so that section has been deleted in the r1. Section 5 contains the actual edits that are being proposed. In the r0, Section 6 had some "rejected" edits, explaining why they are not needed. Section 7 had some "optional" edits. These really are just attempts at wording improvements, so we do not need to rush into them. Both of these sections have been deleted in the r1. 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 pointers, 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. 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 to entry: 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.} ===END===