Sat Jan 25 22:08:48 EST 2014
Van Snyder wrote:
>Now that we've obsolesced the FORALL statement and construct in favor of
>DO CONCURRENT, we no longer have an equivalent as terse as a FORALL
Except that we do. It will be obsolescent, not deleted. "Now" it is not
>As feature creep, could we propose a CONCURRENT statement,
> for consideration at the June WG5 meeting?
For stuff like
CONCURRENT(i=1:n) a(i) = i
is not terser than
DO i=1,n; a(i) = i; ENDDO
and only slightly terser than
DO CONCURRENT(i=1:n); a(i) = i; ENDDO
There is no increase in expressive power, making this suggested feature very
I also agree with Bill that it is adding a wart; to my mind, 2 warts:
(1) omitting the "DO" before "CONCURRENT" is inconsistent syntax - there is
no CONCURRENT construct;
(2) having a statement form of DO CONCURRENT, but not of DO WHILE, DO
forever, or DO loop-control, would be a massive hideous carbuncle on the
If we want brevity let's instead add the synonymic keywords
OD === ENDDO
FI === ENDIF
TCELES = ENDSELECT
EPYT = ENDTYPE
MARGORP = ENDPROGRAM
etc.. Or if that's not concise enough, how about
} === end whatever the innermost scoping unit or construct is.
Robert Corbett wrote:
>I would not mind retaining FORALL statements. They offer
>most of the useful functionality of FORALL constructs
>without much of the complexity of FORALL constructs,
>regarding both implementation and comprehension.
I dispute that there would be any saving of complexity here at all.
>I would like to get rid of the WHERE construct. While
>the WHERE construct is not as bad as the FORALL
>construct, it has much of the same complexity.
There are fairly simple transformations to turn a FORALL construct into a
sequence of FORALL statements. Similarly (but differently), for turning a
WHERE construct into a sequence of WHERE statements.
But such transformations frequently lose performance (often badly).
Requiring the user to write the low-performance version is not an obviously
Turning that sequence of FORALL/WHERE statements back into a construct, i.e.
fusing the loops which might be thought desirable for performance, is
harder. Not much harder perhaps in many cases, but certainly no easier.
And the code is harder to understand!
Complaining that a WHERE construct with multiple assignment is more
complicated than a single WHERE statement would be rather missing the point,
since the alternative is not a single WHERE statement but multiple ones --
so the fusion analysis has to prove that the masks are identical. Except
when they are not (ELSEWHERE and nested WHERE) where instead you have to do
more sophisticated analysis.
In my opinion it is the statement form of WHERE that is obsolescent, if
anything is. And (obviously) FORALL in all its variations.
More information about the J3