Sun Jan 26 00:06:37 EST 2014
The increase in expressive power of a FORALL statement, as compared to a
DO construct, does not occur until it has more than one index
expression. Yeah, you can usually pack it into one line as a somewhat
less terse DO CONCURRENT construct.
forall ( i = 1:n, j = 1:i ) a(i,j) = b(j,i)
do concurrent ( i = 1:n, j = 1:i ); a(i,j) = b(j,i); end do
And if we add palindromic keywords, we need
PROCEDURE === ERUDECORP
On Sun, 2014-01-26 at 12:08 +0900, Malcolm Cohen wrote:
> 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
> even obsolescent!
> >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
> low bang-for-the-buck.
> 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
> winning strategy.
> 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