[J3] Consideration of Paper 18-242 at Meeting 218 (Was: 18-242)

[Bill Long]

I think Vipul is getting close to a workable compromise. 

Just deciding to make the loop variable a construct entity for the existing DO loop is a non-starter.  If this is wanted, a NEW DO form is needed.  The idea of reusing the existing DO CONCURRENT syntax (minus the token CONCURRENT) seems viable.  It would allow

DO ( i=1:n, j=1:m)
…
END DO

which is a shorthand for 

DO I=1,n
  DO j=1,m
…
  END DO
END DO

with the loop body iterations executed in the same order in both cases, but with the loop variables i and j being construct entities, and the optional type specifier allowed after the first ( in the syntax, as with DO CONCURRENT.   There are a lot of actual codes where the loop variable values are not needed  after the loop nest is completed, and this sort of “perfectly nested” loop structure is pretty common. 

While the colon notation for the loop variable range was clearly borrowed from array section notation, I think the stronger motivation for the colon usage is that 

  DO (i=1,n,j=1,m)

is visually confusing, suggesting that j is the stride for the i variable.  So, I think that a better proposal is to stick with the syntax for DO CONCURRENT.  Fewer surprises.  Less “new” for users to learn.

Except for the loop variables becoming construct entities, this new DO form is basically syntax sugar, which has had trouble getting traction with the committee (the poster case being += ).  Still, a revised proposal along these lines would seem to deserve consideration by JoR at the Feb meeting. 

Cheers,
Bill



> On Dec 3, 2018, at 6:11 PM, Vipul Parekh via J3 <j3 at mailman.j3-fortran.org> wrote:
> 
> On Mon, Dec 3, 2018 at 3:26 PM Van Snyder via J3
> <j3 at mailman.j3-fortran.org> wrote:
>> 
>> On Mon, 2018-12-03 at 15:12 -0500, Vipul Parekh via J3 wrote:
>>> do ( integer(8) :: i = n:m ) !<-- NOTE the parenthesis around the loop
>>> header and the colon in control spec as in n:m instead of n,m
>>> ! object i is now a construct entity
>>>   if (a(i) < 0) exit
>>> end do
>> 
>> The colon in the loop control in DO CONCURRENT (and FORALL) was intended
>> to emphasize that iterations are not in any particular order.
>> 
>> The comma in the loop control for the current (and proposed) DO
>> construct are intended to emphasize that the iterations are in the order
>> of the sign of the stride expression.
>> 
>> 
> 
> 
> I couldn't find a reference to such an emphasis in the text of the
> standard, can someone please point me to it?
> 
> Regardless, in the context of the DO construct. any emphasis attempted
> to be conveyed by the colon versus a comma appears superfluous
> considering the monstrosity of the keyword CONCURRENT and what it
> implies about a lack of any particular order in the execution of the
> loop.  I presume it was retained for consistency with FORALL
> construct.  But the value of any additional emphasis with colon looks
> questionable to me, does anyone have any information that points
> otherwise?
> 
> Separately, a loop header such as
> 
> do integer(kind=IK) :: i = n, m
> ..
> end do
> 
> might look alright to some coders in terms of syntax, but I suspect it
> will come across as somewhat odd to others.  Now if I recall
> correctly, the standard allows an optional comma after DO as in
> 
> do, i = 1, 20
> 
> but I have never seen it get used, so I won't comment on it here.
> 
> I also wonder if implementations would have concerns with parsing
> Van's proposed syntax as in <do integer :: i = 1, m>.
> 
> Considering the existing DO CONCURRENT facility in Fortran and what
> many coders will be familiar with in other languages, I think the
> presence of enclosing parenthesis will be preferable.  I would also
> suggest allowing commas in addition to colons in DO CONCURRENT now
> that FORALL is obsolescent.  New coders might find it easier to
> understand the loop-variable inside the parenthesis is a construct
> entity, whether it be in DO or DO CONCURRENT or io-implied-do or
> ac-implied-do or data-implied-do e.g.,.
> 
> do ( integer(kind=IK) :: i = n, m )  !<-- Suggested
> ..
> do concurrent ( integer(int64) :: i = 1, m ) !<-- Suggested - allow
> commas in control section in addition to colon; concurrent keyword
> *sufficiently* conveys lack of order in execution
> ..
> data ( a(I), integer :: I = 1, 10) / 10*1.0 /  !<-- Allowed already
> ..
> y = [( 42+k, integer :: k = 1, size(y) )]   !<-- Allowed already
> ..
> write ( lun, * ) ( x(i), integer :: i=n, m )  !<-- Proposed in 18-242
> 
> Regards,
> Vipul

Bill Long                                                                       longb at cray.com
Principal Engineer, Fortran Technical Support &   voice:  651-605-9024
Bioinformatics Software Development                      fax:  651-605-9143
Cray Inc./ 2131 Lindau Lane/  Suite 1000/  Bloomington, MN  55425