J3/06-157
Title:	Enhanced Readability Do and Forall Blocks
From:	Lee Higbie, Arctic Region Supercomputing Center
Date:	15 March, 2006

Summary:	
	We should add an optional clause to the end of iterative enddo and endforall loops
indicating the iteration parameter. 
 
I see two possible syntaxes:

       do i = ...
           ...
        end do i
or
        do i = ...
           ...
        end do loop i

and, for iterative forall loops, following the first alternative: 
        forall (i = ...
           ...
        end forall i
and
        forall (i = ..., j = ...
           ...
        end forall i, j
etc.	

Rationale:  
	1.  Indentation and other physical code structuring techniques
work only for relatively closely spaced do ... enddo pairs.

	2.  Labeling do statements (with or without labels on their corresponding enddos)
makes it harder to see the structure of blocks because the do statements are obscured by the label.  The blocks are not
as clearly delimited (not shown by the first couple of characters on the line) as those with unlabeled dos.  For iterative loops the do index provides a de facto identifier because of the requirement for unique names.

	3.  With iteration-index-labeled enddos the compiler, maintainer or reader of a program can all
readily check semantics and correct nesting of loop structures
without the annoyance of labels on do statements.  

	4.  The clause on the end of the enddo statements adds
nothing to the semantics of the language for correct programs, so
compilers will not be burdened, but smart editors (like people) will be
able to quickly identify the bracketing of statements implied by the
do and enddo statements.

	5.  It is an obvious extension of the end program [name], end function [name], ... syntax.

	6.  It is, in effect, an extension of the good programming
practice to clearly indicate the pairing of do and enddo statements
with comments.  One way of looking at this enhancement is that it elevates comments on enddos to a standard form that a
compiler should check.
 It should replace part of the useful comment programmers should put on large loops:
        do i ...
	      ...
        enddo ! loop on i that began about 237 lines ago
which is very useful but if the comment is incorrect it may confuse rather than help.

	7.  For those us who maintain code written by others or with structure that we no longer remember, we could add the iteration parameter on the enddo statements in a routine to verify that our mental image corresponds to the actual code blocking because the compiler (or even a good code editor)could or would verify that such loops are properly nested.

Compatibility:
	1.  There is complete backward compatibility because this in no way affects the semantics or syntax of any working program.

	2.  Editors and other tools will more readily help programmers determine the blocking of a program.  For example,
		grep -i “do i” program.F
will show almost none of a program except the starting and ending of loops on i.  If one do-enddo pair does not line up, the programmer will know that there is an indentation error in the code structure.

Futures (feature creep?):  	
	1.  The exit and cycle statements can be extended to include syntax such as
        exit i
or
        exit i loop
or
        exit label i
to provide matching redundancy on exit and cycle statements.  This unambiguously shows the loop that is referenced.  Because of the obvious conflict with labeling do statements, I suggest allowing only one possible label for a loop--either the do statement label or the do index.

	2.  Extending labeling to other endxx statements is more problematic because there is no unique block identifier in most cases.  The one exception is 
        if (booleanVariable) then 
	      ... 
        endif booleanVariable
This structure might help programmers, but does not seem likely to produce similar benefits to labeled enddos.