(j3.2006) CD ballot process

[Van Snyder]

On Wed, 2017-04-12 at 22:09 +0000, Bill Long wrote:

> One reason appeared to be that the user could just insert OpenMP
> directives instead.  There are numerous reasons that is a undesirable.
> These directives apply to OpenMP parallel regions, not Fortran
> constructs.  And their use would involved dragging the whole OpenMP
> infrastructure into the program. But most important, for me at least,
> is that we would be making the Fortran standard dependent on the
> definitions established for directives by the OpenMP committee.  Not
> only is this a potentially bad position to be in, but especially so
> with a committee that is habitually behind in accommodating current
> Fortran standards.

I couldn't find anything in the standard that requires processors to
interpret OpenMP directives in this way, or prohibits to apply OpenMP
directives to DO CONCURRENT constructs.

If OpenMP directives are too oppressive, a preprocessor could convert
non-OpenMP directives into BLOCK constructs inside DO CONCURRENT
constructs.

> The other is to ask users to insert BLOCK constructs inside DO
> CONCURRENT constructs.  Seems like a kludge to me - asking for
> cooperation between two constructs instead of providing a clear spec
> for the single outer one.   And it is less clear how one would
> distinguish between LOCAL and LOCAL_INIT using this scheme.

There were requests during development of Fortran 90 to allow a
specification part in every construct.  This wasn't a radical untried
idea; it was in ALGOL 60, and in the Ada requirements in 1976.  I
proposed it again for Fortran 2003 in February 1997 (97-114r2, page 30).
If putting a BLOCK construct inside a different construct is too
confusing, why doesn't every construct have a specification part?  Why
doesn't DO CONCURRENT have a specification part?

When I suggested to include the functionality of ASSOCIATE in CHANGE
TEAM I was told that it's not confusing and not that much extra work to
put an ASSOCIATE construct inside a CHANGE TEAM construct.  But it's too
oppressive and confusing to put a BLOCK construct inside a DO CONCURRENT
construct.  Weird logic, for some definition of "logic."

People have long asked for a way to initialize a variable in a
declaration, every time a scoping unit or construct is entered, without
imposing the SAVE attribute.  The AUTOMATIC attribute, which would
override SAVE if initialization appeared, was briefly in the 1990 draft,
around about S8.99.  Even without that, a declaration in a BLOCK
construct, and an assignment statement early in the execution-part,
accomplishes LOCAL_INIT.

There are plenty of existing ways to accomplish what locality specs in
DO CONCURRENT would do without adding the goofiness of attribution
without declarations that magically happens because one thing has the
same name as another thing.  There are plenty of ways to accomplish what
locality specs in DO CONCURRENT would do by using more regular
mechanisms that wouldn't preserve the "beloved Fortran tacked-on look"
of a different special widget for every purpose.

I used to propose ways for programmers to give optimization clues to
processors (e.g., 97-114r2 page 17), but every one was shot down with a
statement something like "Our compiler can figure that out without being
told."  What's different about DO CONCURRENT?