I wrote:
> > Concerning GO TO, Walt (quoting a Java book) wrote:
> >
> > 1. ... the author said there were two main reasons to have a
> > goto: exit a loop and handle an exception ....
> >
> > A third reason is to simulate coroutines, AKA reverse communication.
> >
> > Coroutines have been on my Fortran wish-list for about 12 years.
and Alvaro Fernandez wrote:
> Coroutines?
I'll give views of coroutines from four angles.
1. In languages that support coroutines, there are typically two additional
procedure invocation-related statements. In a Fortran extension, these
might be COCALL and CORETURN. COCALL acts like a CALL if the procedure
has never been called, or if it most recently returned by an ordinary
RETURN statement. If it returned by a CORETURN statement, COCALL
returns control to the procedure after the CORETURN statement. CALL
always sends control to the first statement of the procedure.
2. Many mathematical software routines need access to user-supplied code.
The two most common ways to do this are to have a dummy procedure,
to which the user associates an actual procedure, and to call an
external procedure of a specified name. Both of these methods of
access to user-supplied code are troublesome if the user-supplied
code needs parameters in addition to the ones planned for the calling
sequence in the package. In quadrature, for example, the mathematical
software package will provide for passing the integration variable to
the procedure that evaluates the function to be integrated, but most
software packages have no provision to pass any other parameters.
In a spectroscopy application, for example, one might be integrating
with respect to frequency. One may need a spectroscopic database in
order to account for line shape. The quadrature package will pass the
frequency, but provide no provision to pass the spectroscopic database.
To avoid this problem, some mathematical software routines are organized
to allow the package to return to the calling program when access to
user-supplied code is needed. So using a quadrature routine might
look like the following:
what = 0 ! initial call
do
call quadrature ( a, b, x, what, answer, error_estimate )
select case ( what )
case ( 1 ) ! done
exit
case ( 2 ) ! Need a function value
answer = my_function(x, spectroscopic_database)
case ( 3 ) ! some other feature, e.g. intermediate output ....
end select
end do
Inside of the routine, there may be several reasons for needing access
to user-supplied code. In the case of a quadrature routine, one
certainly needs access to user-supplied code to compute the function
being integrated at one of the abscissae of the quadrature formula.
But what if the procedure has a search method to find discontinuities,
and break the region of integration thereat? The routine is almost
certainly needing function values in different places for these two
purposes. Therefore, at the beginning of the routine, there will
be a selection process that sends control back to the correct place.
In my own codes, this is usually a computed-GO TO statement. This
sort of control structure is almost impossible to organize without
GO TO.
3. The relation between a Fortran input/output list and the Format
statement is a coroutine relation.
4. There is a useful programming style called an "iterator". The idea
is like a DO, but the control is "everything in the list of things
produced by a specified procedure." The iterator procedure needs
to start up one way, and proceed a different way. In between, it
needs access to what amounts to the loop body. In a more general
case, it may need to iterate differently after, say, odd- and even-
numbered iterations.
All of these things are easy with coroutines, and difficult without.
I hope that clarifies what coroutines are, why one needs them, and why
some codes need GO TO (given that Fortran doesn't support coroutines
directly).
Best regards,
Van Snyder
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
