(j3.2006) CO_REDUCE as a coroutine

[Tobias Burnus]

Van Snyder wrote:
> When I suggested at 205 that CO_REDUCE ought to be implemented as a
> coroutine, there were chuckles of derision.
>
> Well, here's why it would be a good idea, independently of whether the
> the language that implements it supports coroutines directly, or it
> needs to be simulated in the old-style Fortran 77 method of "reverse
> communication."
>
> If CO_REDUCE invokes OPERATOR, the process that calls CO_REDUCE needs to
> send a descriptor of all of OPERATOR's argument passing methodologies,
> and then CO_REDUCE needs to reconstuct them.  This is messy and
> expensive, both in labor and efficiency.
>
> If instead CO_REDUCE suspends when it needs access to OPERATOR, then
> OPERATOR is invoked from the calling process.  This means the processor
> can create and optimize the appropriate argument passing methods, and
> then resume CO_REDUCE.

>    Something like
>
>    call actual_co_reduce ( A, B, C, D, [, result_image, stat, errmsg] )
>    do while ( suspended(actual_co_reduce) )
>      d = operator ( b, c )
>      resume actual_co_reduce ( A, B, C, D, [, result_image, stat, errmsg] )
>    end do

Not that I fully understand this code or the proposal, but isnt't the 
compiler already permitted to expand the CO_REDUCE to such a code, 
assuming the semantic matches the one of TS18505's CO_REDUCE?

The only real advantage I see with putting the operator call into the 
code is that one might use vectorization for the reduction - assuming 
the user-defined reduction function is simple, the data is contiguous in 
memory, one has an array at the first place and the operator call can be 
inlined. If not all of those points are fulfilled or if the A argument 
of CO_REDUCE has allocatable components, I don't think that it will help.

In any case, I don't think that a change in the TS is required, but it 
can be food for thought for the actual implementation.

Tobias