Re: subroutines as arguments

James Van Buskirk <not_valid@xxxxxxxxxxx> wrote:

"Richard Maine" <nospam@xxxxxxxxxxxxx> wrote in message
news:1ioih8d.1w6exw3138uqomN%nospam@xxxxxxxxxxxxxxxx

I'm not sure I understand your point. My para above was all about how
compilers are not required to catch illegal recursive calls. If this
bears on that, it is passing me by (which is certainly possible).

The point is that in f77,
[elided]
was legal, but
[elided]
was not...

Ah. Ok. I understand that. You just threw me by putting it after a para
of mine that it didn't have much to do with.

Similarly subroutine foo
was passed as an actual argument (in subroutine foo) to
subroutine bar in the original example. This was illegal only
because the was no line

external foo

among the declarations of subroutine foo.

Well, except that an "external foo" statement is illegal in subroutine
foo, independent of issues of recursion. I think it counts as an illegal
duplicate specification or some such thing. I seem to recall an interp
about that somewhere.

Looking around in N1601.pdf, I see that "In an external subprogram,
an EXTERNAL statement shall not specify the name of a procedure
defined by the subprogram."

Ok, you found it. That's the restriction I was thinking of. And I don't
think I buy your whole argument. The basic reason that such an external
statement is invalid is that it is duplicative. The subroutine name
already has the external attribute within itself. So no, I don't buy
that the lack of an external statement is a reason for this being
invalid, since that's just a lack of duplicate information. I also don't
think explicit interfaces have anything in particular to do with the
question.

In fact, I think I'm coming to the conclusion that the original code
shown actually is technically valid, but of very limitted use. The
subroutine does have the external attribute within itself, so that
doesn't make it invalid. I think the fact that it sort of implies a
recursive call is the only problem, and if it isn't actually called,
that isn't actually a problem. As you note, one might use a procedure
pointer (or a C equivalent) to do something useful with it. Those would
require f2003, though. I can't come up with a way it can ever be useful
in standard-conforming f95.

Before f90, DEC Fortran had an extension where procedures were
allowed to be used recursively given an appropriate command-line
switch.

Yes. There were various f77 extensions for recursion. I was sticking
solely to the standard.

--
Richard Maine | Good judgement comes from experience;
email: last name at domain . net | experience comes from bad judgement.
domain: summertriangle | -- Mark Twain
.

Relevant Pages

  • Re: subroutines as arguments
    ... it is passing me by. ... subroutine bar in the original example. ... independent of issues of recursion. ... that the lack of an external statement is a reason for this being ...
    (comp.lang.fortran)
  • Re: subroutines as arguments
    ... That would be the case where bar never ended up invoking the subroutine ... ends up invoking foo. ... compilers might have extensions that allow nonstandard recursive calls. ... allow recursion at all. ...
    (comp.lang.fortran)
  • Re: Yet Another Spinoza Challenge
    ...  > free language can only be compiled with a stack, ... If it also has recursive subroutine call, ...  > has subroutine call, but no recursion, is dead on arrival. ... that was why Fortran was dead on arrival. ...
    (comp.lang.c)
  • Re: perldocs (etc) on recursion in Perl? Dont understand _WCPS_ example
    ... but I know little about how recursion is implemented in Perl ... Let's ignore the fact that he's using a subroutine prototype (Mr. ... This is a subroutine declaration. ... Recursing again, arg = 4 ...
    (comp.lang.perl.misc)
  • Re: Can I have different instances of a subroutine?
    ... subroutine recursively (although no recursion is needed to solve any of ... recursion is not needed but is being used. ... Do the subroutines have internal state ...
    (comp.lang.fortran)