(j3.2006) Colleague has a problem

[Keith Bierman]

Perhaps I'm just a bit dim these days, but why do you think coroutines would
suffice? That is, the IDL folks would need to want to do whatever "magic" is
required to allow such calls; just providing a Standard way to accomplish it
doesn't mean the nonFortran world will care enough to use it.

Or am I missing something?

Keith Bierman
khbkhb at gmail.com
kbiermank AIM
303 997 2749


On Fri, Apr 22, 2011 at 6:50 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:

> 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).
>
>
> _______________________________________________
> J3 mailing list
> J3 at j3-fortran.org
> http://j3-fortran.org/mailman/listinfo/j3
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://j3-fortran.org/pipermail/j3/attachments/20110424/73877210/attachment.html>