To: J3                                                     J3/19-172
From: Van Snyder
Subject: Specification part in more <block>s
Date: 2019-July-05
References: 18-156

Background
==========

Minutes of Berkeley meeting 217 report

  Allowing a specification section in (some) constructs without forcing
  use of BLOCK/END BLOCK seems useful. No paper. Defer discussion to
  next meeting.

There was no discussion at meeting 218.

Proposal
========

Allow a specification part in every <block> of every construct that has
a <block>.

This would be done most simply by adding <block-specification-part> at
the beginning of the definition of <block>, making R1101 read

  R1101 <block>           <<is>> [ <block-specification-part> ]
                                      [ <execution-part-construct> ] ...

and R1107 read

  R1107 <block-construct> <<is>> <block-stmt>
                                      <block>
                                      <end-block-stmt>

A variable declared in a DO CONCURRENT construct is local to each
iteration if it does not have the SAVE attribute, and is otherwise
shared among all iterations.  This is consistent with 11.1.7.5p1.

For consistency with a DO CONCURRENT construct, and with a variable
declared within a BLOCK construct within a DO construct that is not a DO
CONCURRENT construct, a variable declared in a DO construct that is not
a DO CONCURRENT construct is a different variable in every iteration if
it does not have the SAVE attribute, and is otherwise shared among all
iterations.  It is not necessary to add locality specifications to DO
constructs that are not DO CONCURRENT constructs.

It will be necessary to examine and probably revise every appearance of
"BLOCK construct".  In most cases, the revision would consist of
removing "BLOCK".

If <block-specification-part> is added to a subset of constructs, the
revision would consist of, e.g., "BLOCK or IF or DO but not other
constructs".

A BLOCK construct is presently allowed in every construct that has a
<block>, so the present proposal is primarily syntactic sugar.

Allow to specify the ALLOCATABLE or POINTER attribute (but no other
attribute) for an associate name in an ASSOCIATE or SELECT TYPE
construct, provided the selector has the same attribute.  This would
allow to allocate or deallocate the associate name.  This makes the
associate name of an ASSOCIATE and SELECT TYPE construct more parallel
to a dummy argument.  This functionality could be achieved using an
internal procedure, unless the ASSOCIATE or SELECT TYPE construct is
within an internal procedure.