To: J3                                                     J3/19-111r1
From: Van Snyder & Gary Klimowicz
Subject: Instead of += etc
Date: 2019-February-11

Reference: 03-258r1, section 2.15


1. Proposal
===========
C-like "operators" such as += are occasionally proposed.  Of course, if
one wants +=, one also wants -=, *= and /=, but /= is already .NE.

In section 2.15 of 03-258r1, I proposed a more general facility, called
a "pronoun" therein.

The idea was to allow to put a name followed by a special character, "@"
in the proposal, to give a name to an expression.  The example in
section 2.15 of 03-258r1 was to allow to replace

  a(3*i+1) = b(3*i+1)

by

  a ( s @ (3*i+1) ) = b(s)

In the description of pronouns used to identify actual arguments, it
should be made clear that the identified entity, not its value, is the
actual argument.  Beyond that, something such as

  x(3*i+1) = x(3*i+1) + 42 * b(i)

that might have been hoped to have been written

  x(3*i+1) += 42 * b(i)

could be written

  v @ x(3*i+1) = v + 42 * b(i)

If one had instead

  x(3*i+1) = x(3*i+1) * 42 + b(i)

a += or *= operator cannot be used to simplify things, but with a
"pronoun" it could be written

  v @ x(3*i+1) = v * 42 + b(i)

Of course, a statement could include definitions of several pronouns,
which have statement scope, and a statement could not define a
particular pronoun more than once.

2. JoR Review of Proposal
=========================
This proposal has been made at previous J3 meetings and was deemed low
priority for inclusion in the work for the upcoming revision to the
standard (ref. 18-254.txt).

Summarizing these concerns:
    a. The proposal does not include a motivation or use case,
       outside of eliminating the repetition of common subexpressions.
    b. If this is for conciseness for the programmer, the motivation
       does not seem compelling.
    c. If this is for forcing common subexpression elimination,
       this seems like a quality-of-implementation issue, not a
       language issue.
    d. This proposal introduces a new kind of name scope to the
       compilers, statement-level scope. Its interaction with other
       scope management mechanisms (e.g., IMPLICIT statements) is not
       handled in the proposal.
    e. The compiler cannot determine whether the expression being
       referenced is without side effects. The semantics of the
       construct in the presence of side effects seems problematic.
    f. The expression can be easily expressed with the use of
       temporary variables, and arguably, more clearly for the reader:
             ind = 3*i+1
             x(ind) = x(ind) * 42 + b(i)
    g. Using the special character "@" for this purpose may preclude
       Fortran using it for other purposes in the future versions
       of the language.


3. Disposition of Proposal
==========================
It is recommended that this proposal not be added to the work list
for the next revision of the Fortran standard.