(j3.2006) for all comments in c.l.f

[Malcolm Cohen]

Does not seem to add much to the discussion.

>there are potential
>uses of FORALL that don't map across.

I think that no-one claimed that FORALL had *zero* expository benefit, just very 
close to zero.

>  Here's one I found in "someone
>else's" code - in appendix C.4.6 of Fortran 2008:
>
>     J = (/ 1, 2, 3, 4, 5 /)
>     FORALL (K = 1:5) J(K) = SUM(J(1:K) )
>
>Blindly change that to a DO CONCURRENT (K = 1:5); J(K)=...; END DO and
>you are in a world of hurt, without the help of any numbered constraints
>to tell you that things are going to go bad.

Gordon Bennet, anyone writing code like that deserves all they get, when
   J = [ (Sum(j(:k),k=1,5) ]
perfectly captures precisely what is required.  No FORALL required or even 
useful.

Hmm, maybe FORALL really *does* have zero expository benefit, since it 
apparently encourages worse exposition to go along with the worse performance!

>(Make the first sentence of the first dot point in 8.1.6.7 (and perhaps
>the first sentence of the second dot point) a constraint, and my
>concerns evaporate, but the vendors might not like that much... ).

Runtime requirements cannot be constraints.

(It is true that the DO CONCURRENT formulation is slightly askew from both the 
"best performance" and "best diagnostic" or at least "best reproducibility" 
targets, but it does not seem like a bad compromise.)

Cheers,
-- 
................................Malcolm Cohen, Nihon NAG, Tokyo.