(j3.2006) Colleague has a problem

[Van Snyder]

I have a colleague who has a problem that appears to be insoluble.

He wants to use some Fortran math libraries from IDL (and maybe
eventually from Matlab, Octave, PV-Wave....)

The routines he wants to use need access to code he writes --
quadrature, differential equations, minimization, zero-finding,
parameter estimation....

He wants to write his code (integrand, ODE RHS, objective....) in IDL
etc.

IDL is perfectly happy to call Fortran, but won't let him pass an IDL
procedure for the Fortran code to call to evaluate his integrand etc.
(duh).  There is an "IDL kernel" that he could conceivably call from
Fortran, but it wouldn't be the same instance as the one that called the
math library code.  IDL provides a weird sort of common, that he needs
to use to get parameters from his main program to his integrand etc., so
having two instances of IDL won't work.

Some of the math library codes are set up for reverse communication, but
every time they return for an integrand etc., IDL throws away their
instance, so their internal state is gone.

I think his problem could be solved if Fortran had coroutines,
appropriately specified.  I don't see how it can be solved otherwise.

When I first proposed coroutines, Aleks argued that they're not
necessary (nor is reverse communication necessary) because one can pass
a polymorphic "Extra_Stuff" variable from the main program through the
library code to the user-provided subroutine.  This is fine for entirely
new programs, but isn't feasible when updating an enormous legacy code.
If it's littered with reverse communication, telling the owner to
re-write big chunks of it to use forward communication and polymorphic
"extra_stuff" variables is a non-starter.  This means that without
coroutines, providers of math libraries that need to offer reverse
communication to their users are stuck with an ugly GO TO mess, or an
inscrutable state machine, forever.

Now that I have what appear to be two good reasons to want coroutines,
I've dusted off a TR I wrote on the subject and put it on the server in
the Tutorials folder.  It's called Coroutines-TR-3.pdf.

I plan to propose this as a work item, either as a TR or for the next
revision.

Comments welcome.

Frontmatter is four pages.  Then a page of boilerplate.  Then seven
pages of requirements.  Then three pages of examples.  Then seventeen
pages of edits to 10-007r1 (three pages of which are the examples).