<robert.corbett@sun.com> wrote:

Either Bob's missing something or I am. From what I can see, the code is
fine as is, but would be erroneous if an EXTERNAL statement or interface
body were added. Did you miss the fact that other_sub is not external,
but is instead a module procedure in the same module.

Ok, I take it back. Adding an EXTERNAL statement would not make the code
nonstandard, but it would make it mean something different from the
"obvious". That would mean that the other_sub passed to QAG would not be
the module procedure, but would instead be some external procedure of
the same name (assuming such an external procedure existed).

Now within QAG, there better be something to declare its dummy argument
to hav ethe EXTERNAL attribute, but that's a different matter (and an
unfortunately confusing one - for "hysterical" reasons the EXTERNAL
attribute for a dummy procedure just means that it is a procedure and
has nothing to do with it being external).

Although the code is fine as is (I think), you might be able to give the
compiler a helpful hint by declaring something about other_sub before
its use. About the only such thing you can validly declare is the public
or private attribute. I usually tend to do so for module procedures.
Well, for a start I have to do it for public ones because I make the
default accessibility private. I often do it for private ones as well,
partly in order to make the compiler's job a little easier. The public
or private statement at least tells the compiler that, whatever
other_sub is (which can't be determined until the compiler sees the
procedure), it is at least something from the module scope instead of
something local to internal_sub.

Also, moving the code for other_sub before that of main_sub might help.
It isn't required, and I can see stylistic objections in some cases, but
it might make the compiler's job easier.