To: J3 J3/26-168 From: Van Snyder Subject: Comments on 25-159r2 (asynchronous regions, US-04) Date: 2026-June-11 References: 97-114r2 00-317 06-197 25-159r2 Work item US-04 has been postponed. I have a few thoughts on the rationale/discussion paper 25-159r2. It was realized decades ago that semaphores, critical sections, or monitor procedures are essential. It is surprising that they are explicitly excluded, or at least explicitly postponed, by NR1. Underscores are not needed in statements. For exaple, we replaced SYNC_ALL with SYNC ALL. Fortran parsers can handle more than one word, or words separated by spaces or punctuation other than underscore. R5 says that asynchronous regions shall not contain image control statements or references to collective subroutines. This is only a lexical requirement, that can be violated without compile-time detection by procedure references unless some other mechanism is added, something like "asynchronous purity" or "coarray purity" or "collective purity." R6 says dependency chains shall span different lexical scopes. That seems like the same problem as R5. The WAIT statement for asynchronous I/O would work instead of ASYNC_WAIT, so another differently-spelt statement is not needed. But that proposal was already rejected in other contexts, for example waiting for an event. But having a differentll-spelt one for each philosophically identical purpose perpetuates what was identified before 1980 as "Fortran's beloved tacked-on look." R7 requires a mechanism to describe locality of data. The BLOCK construct does this, or allowing constructs in addition to the BLOCK construct to have a does this. But that proposition was rejected when it was proposed in connection to DO CONCURRENT.LOCAL_INIT could have been provided by the long-requested facility for local [scalar] automatic variables that get initial values upon scope activation, without that specification adding the SAVE attribute. That a block is asynchronous, and has a , would be obvious if asynchronous regions were specified by [] BLOCK [, ASYNCHRONOUS [ ] ] rather than by a differently-spelt statement. Or if the differently-spent construct had a . Asynchronous regions were proposed in 97-114r2. An adjunct to asynchronous regions is a FORK-JOIN construct. Bill Long pointed out that this can be done in a perceptually opaque way by enclosing a SELECT CASE construct in a DO CONCURRENT construct. Since it can already be done, syntactic sugar would be helpful. This construct was proposed in 97-114r2, 00-317, and 06-197. Ada users and developers realized several decades ago that their task model intrinsically required overheads, so they invented "protected objects," which are essentially coroutines. Alan Burns and Andy Wellings describe this in "Concurrent and Real-Time Programming in Ada" (July 2007). Have we learned anything from them?