Coroutines

[arjenmarkus]

Coroutines represent a method to let two parts of a program cooperate with each other. The Wikipedia page on corotuines explains the concept. In the context of Fortran programming paradigms, think of the way reverse communication is implemented. Coroutines would make this much easier.

[FortranFan]

From what one can see at J3 websites, coroutines have been proposed, see a recent paper.

This item is not on the Fortran 202X work-list though.

So interested parties can use the long waiting period until Fortran 202Y to develop the idea and perhaps try prototype implementations e.g., in LFortran?

[arjenmarkus]

My, the paper has worked out a complete specification - far better than my half(*)-thought-through idea ;).

(*) Well, "half" is exaggerating it a bit, a more accurate estimate is "one-eighth". I merely thought, let's throw up this concept, so that it will not be forgotten.

[certik]

@FortranFan let's work towards fixing the "long waiting period", as proposed in #36. With enough support in the large community, as well as enough members on the committee, it can happen.

[milancurcic]

Coroutines are one of possible concurrent models. The bottom-line question is whether Fortran needs concurrency (I am not convinced). Although it's possible to write concurrent (not parallel) programs with coarrays, they were not designed to do that.

This perhaps also puts the cart before the horse. Let's discuss whether Fortran needs concurrency (perhaps in #59), and if yes, then it's useful to evaluate different concurrency models.

[FortranFan]

@milancurcic wrote:

Coroutines are one of possible concurrent models. The bottom-line question is whether Fortran needs concurrency (I am not convinced). Although it's possible to write concurrent (not parallel) programs with coarrays, they were not designed to do that.

This perhaps also puts the cart before the horse. Let's discuss whether Fortran needs concurrency (perhaps in #59), and if yes, then it's useful to evaluate different concurrency models.

i don't think there is any doubt or question here. Not only does the Fortran standard in no way seek not to support concurrency, but with the importance given to DO CONCURRENT construct in the language starting Fortran 2008 and the considerable flexibility granted to processors in terms of their concurrency approaches and as well as other design considerations in the standard (e.g. REDUCE intrinsics) as well as other actions by the committee such as actively liasing with OpenMP, Fortran appears to fully affirm broad support toward this aspect. Besides the value of coroutines can come into play when a program is executed in different ways e.g., by means other than a Fortran processor. So it appears to me this feature has several valid use cases.

[klausler]

@milancurcic wrote:

Coroutines are one of possible concurrent models. The bottom-line question is whether Fortran needs concurrency (I am not convinced). Although it's possible to write concurrent (not parallel) programs with coarrays, they were not designed to do that.
This perhaps also puts the cart before the horse. Let's discuss whether Fortran needs concurrency (perhaps in #59), and if yes, then it's useful to evaluate different concurrency models.

i don't think there is any doubt or question here. Not only does the Fortran standard in no way seek not to support concurrency, but with the importance given to DO CONCURRENT construct in the language starting Fortran 2008 and the considerable flexibility granted to processors in terms of their concurrency approaches and as well as other design considerations in the standard (e.g. REDUCE intrinsics) as well as other actions by the committee such as actively liasing with OpenMP, Fortran appears to fully affirm broad support toward this aspect. Besides the value of coroutines can come into play when a program is executed in different ways e.g., by means other than a Fortran processor. So it appears to me this feature has several valid use cases.

DO CONCURRENT is fundamentally broken. It only guarantees to the compiler that the iterations of the loop can be run in any serial order. Its default localization rule (any variable read in an iteration will see the most recent value written in the same iteration, if any) prevents straightforward parallel execution.

[certik]

Let's discuss the "do concurrent" problem in #62.

[certik]

@FortranFan do you remember the committee's feedback on the 19-169 paper that you mentioned above? Let's document the feedback here.

[FortranFan]

@certik wrote:

@FortranFan do you remember the committee's feedback on the 19-169 paper that you mentioned above? Let's document the feedback here.

@certik, one or more attendees from the meeting last August 2019 in Tokyo, Japan will be better positioned to provide feedback. I was unable to attend that meeting. "Officially" the documentation from that meeting minutes is paper 19-169 (and many others) were "out-of-order" and "no action" was taken: https://j3-fortran.org/doc/year/19/minutes219.txt:

No action on the following papers, all considered to be
out-of-order features:
19-169 "Coroutines and Iterators"
19-172 "Specification part in more s"
19-186 "Option to derive an inextensible type"
No action on the following papers, all considered to be
for information only:
19-171 "Ada Committee Liaison Report"
19-175 "Concerning N2165"
19-189 "GNU view on templates"
Also, no action on these containers papers:
19-167 "Preliminary requirements for support for containers"
19-168 "Containers"
19-170 "Specifications and syntax for container support"
Data recommends against US25 (Exceptions)

[vansnyder]

There are more uses for coroutines than concurrency. One of my codes solves a bunch of related problems of different sizes. Numerous arrays depend on the problem size. Profiling showed the code was spending a lot of time in the storage allocator. So I made the arrays automatic, depending upon the maximum size. Iteration over the different problems moved into that procedure. Procedures it needed, that need arrays depending upon the problem size, became internal procedures. The module became a monster.

As coroutines, instead of being internal, each could be in its own module, and invoked with the maximum size, immediately suspending, then resumed with each different size, without re-creating the activation record.

And, of course, iterators are useful independently of concurrency. They're just the function analogue of coroutines.