(j3.2006) CO_REDUCE as a coroutine

[Van Snyder]

There was discussion at 205 about the expense (both in labor and
efficiency) of allowing certain generalities in the OPERATOR argument to
CO_REDUCE.

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

I wasn't thinking of CO_REDUCE as the poster child for coroutines.  It's
just one more example of the usefulness -- but the first one to appear
in the standard as an intrinsic procedure.

Sure, you can fake it by the calling process creating an activation
record, or at least the parts of it that need to be preserved between
suspension and resumption, passing it to CO_REDUCE, and then getting
back to the correct place in CO_REDUCE when its execution sequence
resumes, but it's not as clean as having a SUSPEND statement in
CO_REDUCE, and a RESUME statement in the calling process.