(j3.2006) 14-010

[Malcolm Cohen]

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,
-- 
..........................Malcolm.