To: J3                                                     J3/19-107r1
From:    Van Snyder & Steve Lionel
Subject: Irregularities (index variables)
Date: 2019-February-11
Reference: 18-242

Introduction
============

To reduce surprises, especially for newcomers to (modern) Fortran, it
would be helpful if facilities that have similar purposes had similar
details.

The example under attention here is index variables.

In <ac-implied-do-control>, the <ac-do-variable> can be preceded by
<integer-type-spec> ::.

In <data-implied-do>, the <data-i-do-variable> can be preceded by
<integer-type-spec> ::.

In <concurrent-header>, the <concurrent-control-list> can be preceded by
<integer-type-spec> ::.

This is not possible in <loop-control> in <do-stmt> or <io-implied-do>.

18-242 was rejected by /JOR on Monday, October 15 without plenary
discussion.  The minutes include the remark

   Seemingly syntax-sugar change would have semantic effect.
   No value seen.

There has in the interim been e-mail discussion that suggests that
plenary discussion might have reached a different decision.

Proposal
========

To eliminate this irregularity

(1) <integer-type-spec> :: should be allowed before the <do-variable> in
    <loop-control> in <do-stmt>, with the additional effect that the
    <do-variable> becomes a construct entity.  Because a <do-variable>
    with <integer-type-spec> :: is a construct entity, there would be no
    harm to allow it to have the same name as the <do-variable> of an
    enclosing DO construct.

(2) <integer-type-spec> :: should be allowed before the <do-variable> in
    <io-implied-do-control>.  This would have no semantic effect because
    the <do-variable> is already defined in 19.4p1 to be a statement
    entity.  Because there might be more than one <do-variable> within
    the same statement, and there is no concept of "the scope of an
    <io-implied-do>," a <do-variable> with <integer-type-spec> :: should
    not be allowed to have the same name as the <do-variable> of an
    enclosing <io-implied-do>.

Syntax options for item (1)
===========================

There was some objection to simply inserting <integer-type-spec> ::
before the <do-variable> in <loop-control> in <do-stmt> because this
causes the <do-variable> to become a construct entity.  Some
correspondents remarked that this is a problem.

Alternative 1: Allow inserting <integer-type-spec> ::
before the <do-variable> in <loop-control> in <do-stmt> without
additional syntax to warn that the <do-variable> becomes a construct
entity.

Alternative 2: Allow inserting <integer-type-spec> :: before the
<do-variable> in <loop-control> in <do-stmt>, with additional syntax,
such as parentheses around <loop-control>, to warn that the
<do-variable> in <loop-control> in <do-stmt> becomes a construct entity.

Use Cases
=========

allowing

  do integer :: I = 1, 10
    ! blah blah blah
  end do

or

  do ( integer :: I = 1, 10 )
    ! blah blah blah
  end do

avoids requiring

  block
    integer :: I
      do I = 1, 10
      ! blah blah blah
    end do
  end do

(See earlier papers advocating that all constructs ought to have a
<block-specification-part>).

Editorial effects
=================

In the discussion of the <do-variable> in <loop-control> in <do-stmt>,
it would be necessary to specify that if <integer-type-spec> :: appears,
the <do-variable> becomes a construct entity.  This should be in 19.4p3,
not in 11.1.7.2, for consistency with discussion of the scope of the
<index-name> in a <concurrent-header>, which is specified to be a
construct entity in 19.4p3, not in 11.1.7.2.  A paragraph similar to
19.4p6 will also be needed.

In the discussion of the <do-variable> in <io-implied-do-control>, it
would be necessary to add paragraphs similar to 7.8p2-3.  No new
discussion will be necessary in 19.4 because the <do-variable> in
<io-implied-do-control> is already specified to be a statement entity.

JoR Response
------------

JoR believes that the suggested changes are undesireable and recommends
against their inclusion in the Fortran language.

For the case of a DO statement loop control variable, adding syntax that
changes the scope of a variable is confusing and could introduce
subtle errors during program maintenance.

For I/O implied DO, the do-variable in io-implied-do-control is NOT a
statement entity, and therefore the new syntax would change the variable's
scope. The cited reference of 19.4p1 does not mention io-implied-do:

"A variable that appears as a data-i-do-variable in a DATA statement or
an ac-do-variable in an array constructor, as a dummy argument in a
statement function statement, or as an index-name in a FORALL statement
is a statement entity. Even if the name of a statement entity is the same
as another identifier and the statement is in the scope of that
identifier, within the scope of the statement entity the name is
interpreted as that of the statement entity."

JoR believes that the proposed change would likely have even more
deleterious effects on program correctness.