(j3.2006) 14-010

[Van Snyder]

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
> >statement.
> 
> 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 
> language.
> 
> 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.
> 
> Ditto.
> 
> 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.
> 
> Cheers,