(j3.2006) Two more cases where coroutines would be useful

[Van Snyder]

I've recently encountered two more cases where coroutines would be
useful.

The first one is, in some sense, a generalization of the math software
cases such as quadrature: an iterator.  My large program has one object
represented by a simple data structure.  I could iterate over pieces of
it using a DO statement.  I had to change the data structure to a more
complicated one.  Now I need an iterator.  The obvious thing to do is to
move the bodies of the loops into subroutines, and pass those
subroutines to the iterator.  The problem is that in many cases the
loops are in internal procedures.  So I would need to package up all
local variables used in the loop body and pass them through the iterator
to the loop bodies as a polymorphic variable.  I don't think we're going
to allow unlimited internal subprogram nesting any time soon, are we?

The alternative is reverse communication, which doesn't have the problem
of accessing what are presently local variables, but reverse
communication makes for an ugly iterator.

The second one is rather different.  An important step in our program is
to integrate the radiative transfer equation along several lines of
sight through the atmosphere.  The procedure that does this has about
125 automatic arrays that depend upon the path length.  Measurements
told us that if we made the arrays local to the procedure and created
them separately for each path, we spent an appreciable fraction of our
run time in the storage allocator.  If we made the procedure that does
the integration internal to one that has these automatic variables
declared according to the maximum path length, the run time decreased
significantly.  This has resulted in a module of more than 7,000 lines,
with internal pieces that are essentially not reusable other than by
changing the outer procedure to interpret more fields in its
configuration.  It's becoming quite unmanageable.

A coroutine (or coroutines) would allow me to call it (them) once, which
would create the automatic arrays with sizes depending on the maximum
path length, and then resume it (them) for each different path, which
wouldn't require re-creating the automatic arrays.

Again, an obvious solution is to move the worker bees to other modules
and pass what are now host-associated automatic variables to them in
their calling sequences, but calling sequences with hundreds of
arguments are roughly as unmanageable as 7,000-line modules.