J3/06-157r2 Date: May 10, 2006 To: J3 From: JOR/Whitlock Title: Reply to "Enhanced Readability Do and Forall Blocks" J3 appreciates Mr. Higbie's suggestions below. The proposed syntax extension conflicts with the syntax of construct names defined in Fortarn 2003. J3 believes that the use of carefully chosen construct names along with consistent coding practices can provide an adequate level of readability for all block constructs: loop_i: do i=... ... end do loop_i The construct name must not be the same as the loop index but a readable name can be constructed from the loop index. Construct names are available for ASSOCIATE, DO, FORALL, IF, SELECT CASE, SELECT TYPE, and WHERE. J3 thanks Mr. Higbie for the suggestions but will not pursue this extension for Fortran 2008. ------------------------------------------------------------- Date: 15 March, 2006 To: J3 From: Lee Higbie, Arctic Region Supercomputing Center Title: Enhanced Readability Do and Forall Blocks 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. ---------------------------------------------------------- Lee Higbie, vector Vector 907-450-8688 Arctic Region Supercomputing Center Mail: UAF/ARSC, PO Box 756020, Fairbanks, AK 99775-6020 Physical: UAF/ARSC, WRRB 105-116, Fairbanks, AK 99775 64 d 51' 36.2" north 147 d 50' 46.9" west