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 <variable>
       or "the <expr> 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 <actual-arg>, <consequent-arg>, or <variable>
         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===